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ABSTRACT 



An apparatus and method for providing a medical protocol 
graphic user interface which graphically merges medical 
treatments is provided. The apparatus and method generates 
a plurality of graphic images representing a medical treat- 
ment plan. The graphic images are presented in a chrono- 
logical order based in real or virtual time slots and may be 
viewed in either a flow chart or a chart view format. The 
chart view format may be used by healthcare professionals 
to enter data. The graphical images include an order node, 
result node and flow node. The various nodes may be 
connected to form a healthcare plan assigned to a patient. 
Two separate medical treatment plans may be combined 
with duplicate or conflicting orders removed. 
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USER OPENED BOTH TEMPLATES IN FLOW-CHART 
VIEW AND ALL STEPS TO BE MERGED ARE IN THE 
CORRECT TIME SLOTS. SEE RG 43A. USER 
CLICKS MERGE 



THC ORDER NODES IM THE SECOND TEMPLATE (SEE 
FIG. 498) ARE CREATED. EACH ITEM IN THIS OBJECT 
CONTAINS THE SOURCE OBJECT, TARGET OBJECT 



AND THE NEW RESULTED OBJECT. 



ACCORDING TO THE MERGE OBJECT. THE TOP FLOW- 
CHART VIEW, WHICH 13 THE VIEW FOR THE MERGED 
TEMPLATE WILL BE REDRAWN. Tl-fc NEW TRIPLETS 
BASED ON THE MERGED ORDER 5 WILL BE DRAWN, 
BBANCHESJAHROW) FROM THE NEWLY CREATED F.C. y 
NODE TO THE DESTINATION WILL ALSO BE DRAWN. K 
THE CONTENT OF THE NEW ORDER NODES WILL 
CONTAIN ALL ORDERS BELONGING TO THE ORIGINAL 
ORDER NODE. LESS THE DUPLICATED AND 
CONFLICTING ORDERS. 



BASED ON THE ORIGINAL F.C NODES OF THE 
PREVIOUS TME SLOT, AND THE NEW DESTINATION 
NODE, THE LOGICS IN THE RULES OF THE PREVIOUS „ 

TME SLOTS F.C. NODE ARE COMBINED AND 
ENTERED INTO THE FC. NODE IN THE PREVIOUS TIME 
SLOT OF THE MERGEO TEMPLATE (SEE RG. 4NX) 

1 

NEW ARROWS FROM THE UPDATED FLOW CONTROL I 
NODE IN THE PRESENT TIME SLOT AND THE NEWLY " 
CREATED MERGED TRIPLETS ARE DRAWN. 



THE ORIGINAL TRIPLETS FROM THE TOP PLANS, THE 

ORDER MODES AND THE RESULT NODES ARE RE- 
MOVED FROM THE BOTTOM PLAN, BUT THE F.C NODE y 

OF THE BOTTOM PIAN ARE NOT REMOVED FOR THE 
V£XT WCROE OR TO OONTWUE EXECUTION SEPARATELY 



THE NODE OBJECTS OF THE BOTTOM TEMPLATE ARE 
NOT REMOVED FROM THE PLAN MODE. INFORMATION 
PwOWS FROM THE NEWLY CREATED OBJECTS ARE 
AOOED TO THESE OBJECTS ON THE BOTTOM PLAN - 
SO IT CAN BE EXECUTED SEPARATELY IF USER DOES 
NOT WANT TO CONTINUE THE MERGING FOR THE 
NEXT TIME SLOT. 
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DID THE USER MOVE THE WIN- 
DOW SPLITTER UP OR DOWN. 



800 UP: 
VIEW 

CHART 



DOWN 



801 



NEED TO DISPLAY THE FLOW 
CHART VIEW OF THE PLAN. 



802 



GET THE TIME SLOT OBJECT 
FROM THE PLAN OBJECT; UP- 
DATE THE SCREEN WITH TIME 
SCALE AND UNIT SIZE ACCOR- 
DING TO THE TIME SLOT OBJECT. 



803 



GET THE NEXT NODE IN THE 
PLAN OBJECT AND DRAW THE 
RECTANGLES FOR THE ICONS 
AND LINK IMAGES FOR THE ICONS 
WITH THE PERCENTAGE (IF THE 
PERCENTAGE OPTION OF THE 
TEMPLATE OBJECT IS SET) RE- 
CORDED IN THE NODE OBJECT. 



804 



CHECK IF THE STATE OF THE 
NODE. IF STATE = EXECUTED, 
COLOR THE NODE WITH A 
USER SELECTED COLOR. 



■805 



CHECK IF THIS NODE IS 
DESTINATION OF A PREVIOUS 

NODE. IF YES, DRAW AN 
ARROW BETWEEN THE PARENT 
NODE AND THIS NODE. 




806 



CREATE A TABLE WITH PRE- 
DEFINED NUMBER OF ROWS, 
FONTS, COLOR AND CELL 
. SIZE, ETC. 



-807 



GET THE TIME SLOT OBJECT 
FROM THE PLAN OBJECT AND 
COMPLETE THE REAL-TIME OF 
EACH SLOT AND USE IT AS THE 
LABEL OF EACH COLUMN. DE- 
TERMINE THE MOST PROBABLE 
PATH USING THE ASSIGNED 
PERCENTAGE. 





^—808 


SELECT THE ORDER NODE OF 
THE MOST PROBABLE PATH. 




^-809 


GET DATA FROM THE NEXT 
ORDER ITEM OF THE SELECTED 
NODE, FILL DATA INTO THE 
CELLS OF THE NEXT 
AVAILABLE COLUMN. 




^-810 



GET STATUS FROM THE COR- 
RESPONDING RESULT NODE, 
PUT THE STATUS OF THE ITEM 
IN THE RESULT NODE IN THE 
CELLS OF THE NEXT 
AVAILABLE COLUMN. 



-811 



CHECK THE STATUS OF THE 
NODE. IF STATUS = EXECUTED 
THE CELL COLOR CHANGES 
TO GREY. IF STATUS = ACTIVE 
COLOR IS SET TO WHITE. 




(done) 
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USER OPENED BOTH TEMPLATES IN FLOW-CHART 
VIEW AND ALL STEPS TO BE MERGED ARE IN THE 
CORRECT TIME SLOTS. SEE FIG 48A. USER 
CLICKS MERGE 



A MERGE OBJECT CONSISTS OF ALL COMBINATIONS 
OF THE ORDER NODES IN THE FIRST TEMPLATE AND 
THE ORDER NODES IN THE SECOND TEMPLATE (SEE 
FIG. 48B) ARE CREATED. EACH ITEM IN THIS OBJECT 
CONTAINS THE SOURCE OBJECT, TARGET OBJECT 
AND THE NEW RESULTED OBJECT. 



ACCORDING TO THE MERGE OBJECT, THE TOP FLOW- 
CHART VIEW, WHICH IS THE VIEW FOR THE MERGED 
TEMPLATE WILL BE REDRAWN. THE NEW TRIPLETS 
BASED ON THE MERGED ORDERS WILL BE DRAWN. 
BRANCHES (ARROW) FROM THE NEWLY CREATED F.C. 
NODE TO THE DESTINATION WILL ALSO BE DRAWN. 
THE CONTENT OF THE NEW ORDER NODES WILL 
CONTAIN ALL ORDERS BELONGING TO THE ORIGINAL 
ORDER NODE, LESS THE DUPLICATED AND 
CONFLICTING ORDERS. 



BASED ON THE ORIGINAL F.C. NODES OF THE 
PREVIOUS TIME SLOT, AND THE NEW DESTINATION 
NODE, THE LOGICS IN THE RULES OF THE PREVIOUS 

TIME SLOT'S F.C. NODE ARE COMBINED AND 
ENTERED INTO THE F.C. NODE IN THE PREVIOUS TIME 
SLOT OF THE MERGED TEMPLATE (SEE FIG. 48D.) 







NEW ARROWS FROM THE UPDATED FLOW CONTROL 
NODE IN THE PRESENT TIME SLOT AND THE NEWLY 
CREATED MERGED TRIPLETS ARE DRAWN. 






THE ORIGINAL TRIPLETS FROM THE TOP PLANS, THE 

ORDER NODES AND THE RESULT NODES ARE RE- 
MOVED FROM THE BOTTOM PLAN, BUT THE F.C. NODE 
OF THE BOTTOM PLAN ARE NOT REMOVED FOR THE 
NEXT MERGE OR TO CONTINUE EXECUTION SEPARATELY. 







THE NODE OBJECTS OF THE BOTTOM TEMPLATE ARE 
NOT REMOVED FROM THE PLAN NODE. INFORMATION 
FLOWS FROM THE NEWLY CREATED OBJECTS ARE 
ADDED TO THESE OBJECTS ON THE BOTTOM PLAN 
SO IT CAN BE EXECUTED SEPARATELY IF USER DOES 
NOT WANT TO CONTINUE THE MERGING FOR THE 
NEXT TIME SLOT. 



[ DONE ] 

FIG. 47 
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APPARATUS AND METHOD FOR MERGING 
MEDICAL PROTOCOLS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to providing graphic medi- 
cal healthcare plans (protocols) and in particular a graphic 
user interface, for developing, viewing and implementing 
medical healthcare plans. 

2. Description of the Related Art 

Typically, developing a healthcare plan for providing 
medical services to patients has been a manual exercise. 
Often, a physician will construct a medical healthcare plan, 
including when and how certain medical services should be 
provided to patients on written charts or verbally to medical 
care providers. Generic medical healthcare plans have been 
developed by clinicians and committees, with input from 
other appropriate members of an interdisciplinary care team. 
However, adapting a generic plan to a specific patient further 
requires valuable time and effort to coordinate and manage 
the task. In implementing a medical healthcare plan, a 
variety of individuals will be responsible for providing 
different types of care to the patient and possibly entering 
results from the care provided. 

As can be seen, a number of problems are associated with 
developing and implementing present-day healthcare plans. 
First, communication between those generating the health- 
care plan and those implementing the healthcare plan may 
be ineffective. For example, often, a physician will write 
brief notes on a chart regarding patient treatment. These 
brief notes may be interpreted erroneously, leading to wasted 
time and cost, and possibly detrimental care provided to the 
patient. Also, a chronological list of various treatments or 
services is generally not completed before the healthcare 
plan is initiated. If a complete healthcare plan is developed 
before treatment is initiated, possible errors or duplication in 
treatment may be revealed, and thus avoided, in a particular 
healthcare plan. 

Second, once a healthcare plan is developed for a par- 
ticular patient under a certain set of circumstances, often it 
is difficult to retain or duplicate thai plan for likewise 
patients with similar circumstances. Thus, valuable time 
may be wasted in developing an identical or similar plan. 
Moreover, if a healthcare plan requires a slight modification, 
an entire medical healthcare plan must be developed includ- 
ing the slight modification instead of revising an existing 
healthcare plan. 

In addition, when a healthcare planner orders a particular 
treatment, such as a laboratory test, there may be different 
test results which may require alternate further treatment. 
With present medical healthcare plans, it is difficult to 
construct a healthcare plan based upon various results from 
a specific treatment. A healthcare treatment plan may also 
include multiple healthcare treatments, such as multiple 
laboratory tests, further complicating a healthcare plan. 

Fourth, obtaining costs in typical medical healthcare plans 
is difficult. As described above, there may be alternate 
treatments, depending upon different laboratory test results; 
thus, projecting costs for a particular health treatment plan 
must take into account multiple types of potential treatments 
based on different results from various treatment procedures. 
Without knowing specific costs associated with each step in 
the medical healthcare plan, it is difficult for hospital admin- 
istrators to manage costs and allocate limited resources. 
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Fifth, often a patient may require multiple healthcare 
plans that must be reconciled or merged into one plan. For 
example, if a patient is admitted to a hospital for a hip 
replacement and subsequently is diagnosed as having an 

5 infection, two separate healthcare plans must be imple- 
mented. These two plans can be carried out in parallel or 
merged in one to be carried out as one plan. In either case, 
a healthcare plan for the hip replacement must be reconciled 
with the healthcare plan for the infection. The timing and 

10 types of treatment, including drug dosages, must be recon- 
ciled in order to provide treatment for both conditions. 

Finally, once a successful medical health treatment plan is 
developed, reusing that plan, or transferring that plan to 
other healthcare providers, is limited. For example, a leading 

15 cardiologist who develops a healthcare plan for a new 
surgical procedure may not be able to readily transfer the 
healthcare plan to other cardiologists to be adapted and used 
in their practices. Thus, valuable time and effort would be 
saved in developing a single successful medical healthcare 

2 q treatment plan and transferring it to other healthcare pro- 
viders. 

Therefore, it is desirable to provide an apparatus and 
method for providing a medical healthcare plan which will 
1) reduce errors associated with communications between 

25 healthcare planners and providers; 2) allow for convenient 
modification of medical health treatment plans; 3) provide 
costs associated with each step in the medical health treat- 
ment plan, as well as the total cost of the medical health 
treatment plan; 4) reconcile two or more healthcare plans; 

30 and 5) copy and transfer medical treatment plans to various 
medical healthcare providers. 

SUMMARY OF THE INVENTION 

Other aspects and advantages of the present invention can 

35 be seen upon review of the figures, the detailed description, 
and the claims which follow. 

According to the present invention, a data processing 
apparatus is provided. The data processing apparatus com- 
prises a display for displaying data and input means for 

40 inputting data. A storage location is coupled to the display 
and the input means. Processing means controls the storage 
means, input means and the display means in response to 
stored programs and input data. The display includes a 
plurality of graphic icon images, stored in the storage 

45 location, arranged on the display representing a medical 
treatment plan. A program merges a first set of graphic icon 
images with a second set of graphic images to obtain a 
combined treatment plan. 

According to an aspect of the present invention, the first 

50 set of icon images are arranged in a chronological order and 
a first icon image represents the medical order. The icon 
images may be assigned to a patient. Further, the first set of 
icon images and the second set of icon images may be 
arranged in a combined chart view. 

55 According to another aspect of the present invention, the 
first set of graphic icon images includes at least one order 
triplet having an order node, result node and flow control 
node. 

According to yet another aspect of the present invention, 
60 a method for displaying a graphic representation of a medi- 
cal treatment plan is provided. The method comprises the 
steps of providing a first and second set of icon images 
representing a first and second medical treatment. The first 
set of icon images are combined with the second set of icon 
65 images to obtain a third set of icon images representing a 
merged medical treatment, including the first and second 
medical treatments. 
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According to another aspect of the present invention, the 
method step for providing a first set of icon images further 
includes the step of arranging the first set of icon images in 
corresponding time slots with the second set of icon images. 

According to still another aspect of the present invention, 
the method step for providing a first set of graphic icon 
images includes a step for providing a order triplet. The 
order triplet includes an order node, result node and Flow 
Chart node. 

According to another aspect of the present invention, the 
method further includes the step of providing a first order 
icon image having a corresponding order description and 
providing a second order icon image having a. corresponding 
order description- 
According to another aspect of the present invention, the 
method step of combining further includes the step of 
combining the first order description with the second order 
description. 

According to another aspect of the present invention, an 
article of manufacture, including a computer readable 
medium having a computer readable program means for 
displaying a medical treatment plan is provided. The com- 
puter readable program code means in the article of manu- 
facture comprises a computer readable program code means 
for causing a computer to generate an image on a display 
representing a medical treatment. The article of manufacture 
further includes computer readable program code means for 
causing a computer to generate a first and second image 
representing a first and second medical treatment, 
respectively, on a display. Computer readable program code 
means are also provided for combining the first and second 
image to display a combined medical treatment plan. The 
first image includes an order triplet, including an order node, 
a result node and a flow control node. 

According to another aspect of the present invention, the 
article of manufacture further includes a computer readable 
program code means for causing a computer to generate a 
chart view of the first and second images. 

According to still another aspect of the present invention, 
the article of manufacture further includes computer read- 
able program code means for causing a computer to generate 
the merging medical treatment image in time slots on a 
display corresponding to the first and second medical treat- 
ment image. The first medical treatment image is the master 
treatment image, while the second medical treatment image 
is the merging treatment image. 

According to another aspect of the present invention, the 
article of manufacture further includes computer readable 
program means for causing a computer to compare a first 
order node image to a second order node image. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates an example of a Template Builder 
window with an open template according to the present 
invention. 

FIG. 2 illustrates an example of a Cost view according to 
the present invention. 

FIG. 3 illustrates an example of Patient Charting view 
according to the present invention. 

FIG. 4 illustrates an example of a Plan Assignment 
window according to the present invention. 

FIG. 5 illustrates an example of an Export window 
according to the present invention. 

FIG. 6 illustrates the clinical template according to the 
present invention. 
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FIG. 7 illustrates the main directory according to the 
present invention. 

FIG. 8 illustrates the Template Builder window according 
to the present invention. 
5 FIG. 9 illustrates the Template with a Start node and an 
Order Triplet according to the present invention. 

FIG. 10 illustrates separating the Order node from its 
associated nodes according to the present invention. 
10 FIG. 11 illustrates the Order Node Detail dialog box 
according to the present invention. 

FIG. 12 illustrates the Add Orders dialog box according to 
the present invention. 

FIG. 13 illustrates the Order Node detail box according to 
15 the present invention. 

FIG. 14 illustrates the Result Node detail dialog box 
according to the present invention. 

FIG. 15 illustrates the Results Form dialog box according 
2Q to the present invention. 

FIG. 16 illustrates adding the virus triplet according to the 
present invention. 

FIG. 17 illustrates adding the strep triplet according to the 
present invention, 
25 FIG. 18 illustrates adding an Exit node according to the 
present invention. 

FIG. 19 illustrates the connections between the nodes 
according to the present invention. 

FIGS, 19a-19c illustrate various types of connections 
30 according to the present invention. 

FIG. 20 illustrates the Flow Control Node dialog box 
according to the present invention. 

FIG. 21 illustrates how to add the rule using the Rule 
35 Editor dialog box according to the present invention, 

FIG. 22 illustrates a completed rule according to the 
present invention. 

FIG. 22a illustrates an Ongoing order according to the 
present invention. 
4° FIG. 22b illustrates an Ongoing order rule editor accord- 
ing to the present invention. 

FIG. 23 illustrates a template containing Plan nodes 
according to the present invention. 

FIG. 24 illustrates a Plan Node Detail dialog box accord- 
ing to the present invention. 

FIGS. 25A-25B illustrate a logic flow diagram of build- 
ing a template according to the present invention. 

FIG. 25c illustrates a logic flow diagram of determining 
50 cost according to the present invention. 

FIG. 26 illustrates the standard server object interface 
according to the present invention. 

FIG. 27 illustrates the server object relationship according 
to the present invention. 
55 FIG. 28 illustrates the creation of instances on different 
host machines according to the present invention. 

FIG. 29 illustrates an example library hierarchy according 
to the present invention. 

FIG. 30 illustrates a system library interface according to 

60 , . . 

the present invention. 

FIG. 31 illustrates the Plan Assignment dialog box 
according to the present invention. 

FIG. 32 illustrates how to open a patient's plan according 
6S to the present invention. 

FIG. 33 illustrates patient charting in Flow Chart view 
according to the present invention. 
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FIG. 34 illustrates a Result Node Detail dialog box 
according to the present invention. 

FIG. 35 illustrates the Order Result Entry Form according 
to the present invention. 

FIG. 36 illustrates a completed order status according to 
the present invention. 

FIGS. 37-39 illustrates a patient chart according to the 
present invention. 

FIG. 40 illustrates a logic flow diagram of a Flow Chart 
and Chart view according to the present invention. 

FIG. 41 illustrates the plan elements exported from the 
"clinic.pln" and imported into an Excel spreadsheet accord- 
ing to the present invention. 

FIGS. 42-42o illustrates the Plan Assignment dialog box 
according to the present invention. 

FIG. 43 illustrates a Flow Chart view of two templates 
according to the present invention. 

FIGS. 44—46 illustrate a mergiog of two templates accord- 
ing to the present invention. 

FIG. 47 illustrates a logic flow diagram of merging two 
templates according to the present invention. 

FIGS. 4&a-48e illustrate a logic view of merging one time 
slot of two template nodes according to the present inven- 
tion. 

DETAILED DESCRIPTION OF THE 
INVENTION 

I. OVERVIEW 

A. Software and Hardware Environment 

The term "template" is used to refer to a generic health- 
care treatment plan, protocol, or guideline. After a template 
has been assigned to a general patient or client, the template 
is referred to as "plan". 

The software or computer readable program code, accord- 
ing to one embodiment, used in developing, displaying and 
implementing templates and healthcare treatment plans, is 
named the ARAXSYS™ Solution. In a preferred 
embodiment, the ARAXSYS™ Solution software is stored 
on a computer readable medium. 

The ARAXSYS™ Solution program is written in C++ 
language and is stored on a computer readable disk. In the 
preferred embodiment, the ARAXSYS™ Solution software 
program would be used in conjunction with a computer 
system having the following requirements. The computer is 
an International Business Machine ("IBM") compatible 
computer having a 386, 486 or Pentium processor. The 
operating system would be either a MICROSOFT® WIN- 
DOWS® 3.1, WINDOWS® for 3.11, WINDOWS® 95 or 
WINDOWS™ NT operating system. The minimum random 
access memory ("RAM") would be 8 megabytes ("MB 1 ') 
and preferably 16 MB. For relatively small RAM systems, 
virtual memory must be set as high as possible. In an 
embodiment, virtual memory must be set to a minimum of 
12 MB In the preferred embodiment, the Araxsys™ Solution 
program would operate in conjunction with MICROSOFT 
foundation class ("MFC) software files and with WIN 32s 
software files in a 16-bit environment. Available hard disk 
drive space should include 2 to 7 megabytes depending on 
the size of the data and whether or not MFC or WIN 32s 
system files are being used. The monitor would preferably 
be a video graphic adapter ("VGA") or super video graphic 
adapter ("SVGA") color monitor. 

In the preferred embodiment, the computer system would 
have an input/output device, such as a mouse, for "clicking" 
graphic elements. Clicking graphic elements refers to posi- 
tioning a cursor on a display, which is controllable by the 
mouse, on or near a graphic element and pushing a mouse 
button. 
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B. Graphic User Interface Overview 
FIGS. 1-5 illustrate a general overview of display win- 
dows and features used in the present graphic user interface 
according to the present invention. 

5 FIG. 1 illustrates an example of a Template Builder 
window with an open template. The template graphically 
represents a medical healthcare treatment plan in upper 
window 10. The upper window 10 shows a Flow Chart view 
11 of a medical healthcare treatment plan. The template 

10 contains a number of graphic elements including: a start 
node, three triplets of an order node, a result node, a flow 
control node and an exit node. These graphical elements are 
positioned in window 10 in order to represent a medical 
healthcare treatment plan. The graphical elements can be 

15 positioned in time slots, as seen in FIG. 3, which will be 
discussed in detail below. 

In Flow Chart view 11, the process flow begins with a 
Start node, enters into the first Order nodes, and flows out to 
Result nodes. After the results are entered, the process flow 

20 continues on to a Flow Control node where the next step in 
the treatment is determined. As described below, there are 
three types of process flows. 

The bottom viewing window 20 contains two different 
views of the template, each on separate tabs: Zoom view 21 

25 and Cost view 22. A user flips between these views by 
clicking the corresponding tab. A user can also choose Zoom 
view and Cost view options from a View menu to show a 
specific template view. 
The Zoom view is used to see the details inside the nodes 

30 of the template. Each node is magnified or expanded to show 
information contained within, as well as the relationships 
between the nodes in the flow chart. A user can use this view 
to examine the entire template. 
FIG. 2 illustrates an example of a Cost view 22. The Cost 

35 view 22 illustrates the cost associated with a medical health- 
care template. The Cost view helps a user analyze the cost 
of treatment specified by a template. Cost view 22 also 
shows every possible path through the template and lists the 
cost of each path. Each row in the table of cost view 22 

40 represents a single path through the template. The left most 
cell of each row contains the cost of that entire path. The 
remaining columns in the row represent the order nodes in 
the path. Each order node is listed with its associated cost 
and the current accumulated cost. 

45 FIG. 3 illustrates an example of Chart view 30. Each step 
is represented by two columns. The first column represents 
order items in the node and the second column represents 
results status of the order. In each order node, there may be 
multiple order items or multiple instructions or directions in 

50 treatment. Therefore, there are multiple rows per column. An 
order item may also include healthcare business orders, such 
as verifying the insurance of a patient. In this view, health- 
care providers are able to input data at various stages of a 
healthcare template or plan using the results columns. In 

55 addition, healthcare planners and providers can see which 
treatment steps have been completed by review of the color 
of the columns — grey as completed, white as active. The 
Charting view 30 is used to input data and track patient 
progress view according to the patient plan. Flow Chart view . 

60 31 corresponds to the patient chart view. In Flow Chart view 
31, it is the same window in which a user builds templates, 
except the flow is now "active." In other words, a user can 
start the flow, enter order result into the various nodes, and 
move through the flow as the treatment progresses using the 

65 Flow Chart view instead of the Chart view if a user desires. 
Color-coding on the nodes show which ones are completed 
and which are in progress. 
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FIG. 4 illustrates an example of a Plan Assignment addresses a similar condition, modify the template as 

window 40. In this window, a completed template can be needed, and start the patient treatment using the modified 

assigned to a patient. This step merges a template with a template 

patient's plan and enables a care provider to carry out the B. Clinical Template Example 

patient's healthcare plan, which may include various tem- s In this example, a simple template called the Clinic 

plates. FIG. 4 illustrates the templates assigned to the patient Template 60, as shown in FIG. 6, is built to treat a patient 

"John Sanders." complaining of a sore throat. FIG. 6 illustrates graphically a 

FIG. 5 illustrates an example of an Export window 51. medical healthcare template to treat a sore throat condition 

The present invention allows for patient plans to be con- in a Flow Chart view. A simplified work flow for a sore 

verted into generic templates or exported to other software ™ Ihtoat condition can be represented below: 

tools for analysis. A user can export patients' plans in a 0n the first visit ™ih the patient, a healthcare provider 

specific format, or American Standard Code for Information gathers routine vital statistics (i.e., temperature, weight, etc.) 

Interchange ("ASCII") by using Export Button 50. and takes * ur °at culture. Astrep testis ordered from the lab. 

tt m in niNjr tciudf atfc If tne result of ^ stre P tes * 15 De S auve > g° to toe second step 

* <Z . \, J/Ti ^ , 35 and treat me patient assuming the sore throat is from a virus. 

A. Creating a Medical Treatment Template Tf me M q{ ^ step ^ js gQ tQ ^ step and 

Before a user can create a template, treatment work flow treat ^ patienl for strep mroat 
must be defined; that is, the order in which treatment If the strep test was negative,' give the patient self treat- 
activities are carried out for a given condition. mC nt instructions for a viral infection. Exit the work flow. 

A template is constructed from graphic elements or build- 20 If the strep test was positive, give the patient a prescrip- 

ing blocks called "nodes." There are five kinds of nodes: tion for penicillin and self treatment instructions for strep 

Start, Order, Results, Flow Control, and Exit. Every tem- throat - Exit the work flow, 

plate has a Start node, which indicates the start of the L Crcatin g a New Template 

template. Likewise, every template has at least one Exit Usin S me sore throat work flow P rotoco1 above > a health - 

node, which indicates the end of the template. Between the 25 f are ,P la ™ er de f velo P m t e C f hm k c T * ra P Iate 60 > a 

' . r> ■* j • j r» 1* j ™ treatment template for a patient who has a sore throat. The 

Start and Exit nodes are a series of Order, Results, and Flow ia lnttt , . , . , , ^ 

' ' template may be used by any physician or healthcare pro- 
Control nodes. Wl ^ x wnerj determining whether a sore throat is due to a 

Order nodes contain generalized orders placed during the virus or strep, 

course of a treatment. The Order node defines a list of 30 Building a Clinical Template 60, as shown in FIG. 6, is 

generalized orders or healthcare treatment related activities initiated by clicking the Build Templates button 70 on the 

"order items" that are carried out at a given step in the Main Director 71, as shown in FIG. 7. The ARAXSYS™ 

template. Order descriptions may be placed into Order nodes Solution Main window 85 appears in Template Builder 

from a library. Each order is described using attributes that modc ^ illustrated in FIG. 8. In this mode a user builds, 

include category, subcategory, name, description, cost, and 35 rev * c ™ and modifies f neric health templates. In an 

duration embodiment, a new template automatically contains a Start 

The Result node shows the status of the orders in the toolbox 81 is located on the right hand border of 

corresponding Order node. Durmg patient charting, order window 85 Toolbox gl conUins five tools> each presented 

results are entered to the Result node. Result nodes contain 40 by an icon, that aid in building templates. The five tools are 

order status (i.e., an order was done or not done) and result Selection 81a, Generalized Order Triplet Slb t Plan Node 

values (i.e., electrolyte measurements). 81c, Exit Node 81a" and Connection 81c. 

Flow Control nodes contain rules that govern the branch- The Template window is divided into columns by dotted, 

ing among nodes in the template. The Flow Control node vertical lines 82. These lines divide the template into time 

contains rules that select a branch at a decision point in a 45 intervals tha t advance in time from left to right. Headings at 

template or plan, and estimates of the likelihood of branch- me t0 P of eacl J fl umn lat > el each time slot. By default, the 

ing down given paths. During patient charting, the Flow U f me th slot f. arc lab f C " * ^ a Y* c * 

J* A . , r , . ^ r A of otoer time slot labels that may be selected. The width of 

Control node suggests the next step to the healthcare pro- mc ^ ^ {& ^ adjustable 

vider based on the rules and the results entered in Result 50 2 Placing 0rdefj Results> and Flow Control Nodes 

nodes. A typical rule in a Flow Control node looks like this: (Triplets) 

If(Rel:CBC:Hct:Val<-25)GOTO Transfusion at 5%. FIG. 9 illustrates adding an Order node Orl, Result node 

When building a template, nodes are positioned in the Rel and Flow Control node FU to a template. The Order 

chronological order in which they are to be carried out or node Orl contains the physician's orders, such as lab tests, 

executed. A user defines each node and connects the nodes, 55 nursing procedures, x-rays, prescriptions, and other kinds of 

Template creation involves the following activities: (1) treatments or actions These generalized orders may be taken 

placing Order, Results, and Flow Control nodes in their from a library and placed in Order node Orl. The Order node 

proper sequence; (2) filling in the orders (i.e., treatment Orl groups all of the orders for a given step in the template, 

procedures, medicine, and advice); (3) placing an Exit node An Order triplet is entered by clicking the Order tool Sib 

at me end of the template; (4) deciding on the circumstances 60 in toolbox 81. The cursor turns into the icon shape. By 

and order in which each template step is executed during moving the cursor to the right of the Start node and clicking 

treatment; and (5) saving the template. once, an Order triplet is placed into the template. A series of 

Thus, when a physician prescribes treatment for a condi- three nodes appears. Every Order node Orl automatically 

tion addressed in an existing template, a stored treatment has one Result node Rel and one Flow Control node Fll 

template can be used instead of creating a new one. If a 65 attached to it; therefore, whenever a user places an Order 

treatment template does not exist for a given condition, a node from the toolbox, a triplet is actually selected and 

physician may retrieve a template from the library that positioned. 
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In an embodiment, order node Orl may be separated from 
Result node Rel by clicking and dragging the Result node 
Rel to the right to set it off from Order node Orl, as shown 
in FIG. 10, Another embodiment allows a user to choose the 
time scale setting from the.Options menu 86 and increase the 
size of the number of units per slot unit from 5 to 7. This will 
increase the space between the time slot separators (the 
dotted lines 82). The chronological order of a template may 
be either in real time or virtual time. Real time is the current 
active lime of a triplet or plan and active virtual time is a 
time set by the user. 

3. Naming a Node 

To make it easier to follow the template, a user may assign 
a name to each node in place of its default. For example, the 
default name for the first Order node Orl is "Orl", but that 
doesn't tell a user much about the procedures within that 
node. Since the first step in the Clinic Template determines 
whether or not the patient has Strep throat, a user may assign 
the name "Strep?" to Order node Orl by: 

a. Click Order node Orl to select it. 

b. Choose Name from the Edit button 119. 

c. In the Order Node Detail dialog box, type Strep? in 
Name field. 

d. Click OK button 113. 

The word "Strep?" now appears under Order node Orl. 
Next, a user may place orders in the Order node. 

4. Placing an Order 

FIG. 11 illustrates the Order Node Detail dialog box 110 
according to the present invention. 

By double-clicking Order node Orl in the triplet shown in 
FIGS. 9 or 10. The Order Node Detail dialog box 110 
appears showing the list of orders (i.e., content) in Order 
node Orl. There are no orders shown in FIG. 11 in the Order 
node. 

The top of this dialog box 110 contains two "tabs"; 
Attributes 111 and Content 112. 

The following lower buttons have the associated action: 
OK button 113 saves changes made in this dialog box 

when clicking. 
Cancel button 114 closes dialog box 110 without taking 

any action when clicking. 
Apply button 115 currently remains disabled. 
Help button 116 displays Help for dialog box 110 when 

clicking. 

The upper buttons at the top give a user four choices: 

Add button 117 adds an order to be carried out when this 
template is executed when clicking. 

Replace button 118 replaces the selected order with 
another work order when clicking. 

Edit button 119 edits the detail of the selected order, 
including the order's result values when clicking. 

Delete button 120 deletes the selected order when click- 
ing. 

FIG. 12 illustrates the Add Orders dialog box 122 when 
clicking add button 117, shown in FIG. 11, according to the 
present invention. 

All the orders stored in the library appear in the Command 
List area 121. The work orders in the library are organized 
by category and department and are displayed as file folders. 
The Library folder contains category folders, which in turn 
contain folders identifying the departments that typically 
carry out the orders. Each department folder contains a 
series of work orders for the selected category and depart- 
ment. 

In the first step of the Clinic Template, two work orders 
are specified: a strep throat culture, and the routine nursing 
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vital statistics. These work orders are added to the Order 
node Orl by the following steps: 

a. Use the up/down arrow keys 129 to scroll through the 
list, and double -click the Labs folder in the Command 

s list to open it. 

b. Double-click the Bacteriology folder, and then click 
Strep ($40.00) to pick the strep test. This work order 
appears in the Work Order area 125 at the top of this 
dialog box. 

10 c. Click the Place Order button 127 to add the order to (he 
list of orders in the Orders dialog box. 
d. Scroll to the bottom of the Command List, and then 
double -click on the Vitals folder. 

15 e. Double -click Nursing, and then click Routine ($20.00) 
as the order to be performed. 

f. Click Place Order button 127. 

g. Click Done button 124. The Add Orders dialog box 123 
goes away. Both of the work orders the user placed are 

20 listed in the Orders dialog box 110 as shown in FIG. 13. 
If the user accidentally placed the same order more than 
once or placed the wrong order, select the order and 
click Delete button 120 to remove it. 

h. Verity that all of the work orders you selected are listed 
25 correctly, and using the buttons across the bottom of the 

screen, click OK button 113. The Order Node Detail 
box 110 goes away and a user can see the template. 
Thus the contents of the strep? Node shown in FIG. 6 is 
filled according to the present invention. The number 2 
30 above the strep? node shown in FIG. 6 indicates the number 
of orders it contains. For every work order, there is a 
corresponding order result in the Result node Re. Since two 
work orders have been selected, there are two results in 
Result node Re. 
35 Next, a user may view the contents of the Result node. 
5. Viewing the Result Node Content 
The Result Node dialog box 140, as illustrated by FIG. 14, 
lists the status of orders placed in corresponding Order 
nodes. Completed work orders show a "Done" status and 
40 incomplete work orders show a "Not Done" status. Orders 
may also show an "Exception" status if the order cannot be 
filled as expected. 

FIG. 14 illustrates the Result Node Detail dialog box 140 
according to the present invention. Double-clicking Result 
45 node Rel presents Result Node detail box 140. Clicking 
content tab 142 displays the content page. All of the orders 
show a "Not Done" status on the content page because a user 
is still in the Template Builder mode. 

Double clicking the Vitals order 143 in the list of orders, 
50 Result Form 150 is displayed, as shown in FIG. 15. This 
form is where a care provider enters the results of the vitals 
order when the template is being charted as part of a 
patient's plan. 

When charting a patient, healthcare providers enter results 
55 of the vital statistics and set the status to "Done" in Result 
Form 150. This will mark the entire order as "Done" in the 
Result Node Detail dialog window 140. 

Clicking Cancel button 151 closes the Results Form 
dialog box 150 and clicking OK button 144 closes the Result 
60 Node Detail dialog box 140. 

Next, a decision based on the results of the lab work 
requested in the first Order node Orl must be made. As for 
the lab results, there are only two possibilities: either the 
sore throat is due to a virus or it's due to strep bacteria. So, 
65 a user needs to add two more Order nodes: one to hold the 
work orders if the strep test is negative, and another to hold 
orders if the strep test is positive. 
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6. Adding More Order Nodes 

To handle these two possibilities, a user adds two more 
Order triplets, one triplet for each possible branch in the 
treatment course. A user may name the first triplet "Virus" 
and the second one "Strep/* The Virus node will describe 
what to do if the patient has a sore throat due to a virus. The 
Strep node will describe what to do if the patient has strep 
throat. 

Clicking the Order node tool 81c and dragging it to the 
right of the Fll node, and click once positions the Order 
triplet. 

Initially, the Orl appears beneath the Order node. By 
default, each triplet a user creates is numbered in consecu- 
tive order, starting with the number 1. Since the first Order 
node Orl is renamed Strep?, the new Order node is num- 
bered 1 by default. However, since the first Result and Flow 
Control node are still numbered 1, the second set of Result 
and Flow Control nodes are assigned the number 2. Order 
node Orl may be renamed before assigning work orders to 
the new Order node. 

Orl node is selected by clicking it. 

Name is chosen from an Edit menu or double click Orl 
node to show the Order Node Detail dialog box 110 and 
click the Attribute tab 111 as above. 

In the Node Attribute dialog box that appears, type Virus 
in the Name box and click OK button 113. The word "Virus" 
now appears in place of Orl. The Result node must be 
dragged over a bit to separate it from the Order node, as 
shown in FIG. 16. 

An additional triplet may be added by the above steps. 
However, this time, the triplet would be positioned below 
the Virus triplet and the new Order node would be named 
"Strep", as shown in FIG. 17. 

Work orders to the Virus and Strep Order nodes then must 
be assigned. One work order will be assigned to the Virus 
node and two work orders to the Strep node. 

7. Assigning Work Orders to Nodes 

To assign work orders for the Virus node: 

a. Double -click the Virus node. 

b. Click Add button 117 in the Orders node detail dialog 
box 110. Patients with sore throats caused by a virus are 
to be discharged with a discharge direction sheet. 

c. Double -click the DCPlan folder in the Command list in 
add orders dialog box 122 shown in FIG. 12. Discharge 
direction sheets are grouped by department. 

d. Double -click the Clinic folder, and then double -click 
DC_lnstructions_for_ Virus ($0.00) to select the 
work to be performed. 

e. Click Place Order button 127 to add the order to the list 
in the Orders dialog box. 

f Click Done button 124. The Add Orders dialog box 122 
goes away. 

g. Verify that only the work order the user selected is 
listed, and then click OK button 113. The Orders dialog 
box 110 goes away. 

A"l" appears above this second triplet, as shown in FIG. 
18, indicating one work order is assigned. 

To assign work orders for the Strep node: 

a. Double -click the Strep node. 

b. Click Add button 117 in the Orders dialog box 110. 
Patients with sore throats caused by the strep bacteria 
are treated with two work orders: DCPlan Clinic and a 
ten-day dose of penicillin. 

c. Double-click the DCPlan folder in the Command list in 
Add Orders dialog box 122 to open it. 
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d. Double-click the Clinic folder, and then double -click 
DC__Instructions_for„Bacteria ($0.00) to select this 
work order. 

e. Click Place Order button 127 to add the order to the list 
in the Orders dialog box. 

f. Double -click the Meds folder in the library list. 

g. Double-click the Pharmacy folder, and then double- 
click PO_Penicillin_(S 10.00) to select this drug. 

h. Click Place Order button 127 to prescribe the drug and 
add it to the list in the Order node detail dialog box U0. 

i. Click Done button 124. 

j. Verify that only the work orders you selected are listed, 
and then click OK button 113. 

A "2" appears above this triplet, as shown in FIG. 18, 
indicating two work orders are assigned. A template con- 
taining a Start node and three triplets having orders, treat- 
ment results, and flow control has been developed. The last 
node to add to the template is the Exit node Exl. The Exit 
node simply marks the end of the template, like the Start 
node. 

8. Adding an Exit Node 

An Exit node Exl is positioned by clicking the Exit node 
toolbox 81c, selecting and placing it to the right of the other 
nodes, as shown in FIG. 18. 

Now that nodes are in place, connections between them 
must be made. A connection tool 81e in toolbox 81 is used 
to specify the flow between the different sets of orders. 

9. Connecting the Nodes in the Template 

The Flow Control node contains the rules that determine 
which set of orders are followed. Flow Control nodes are 
connected to one or more Order nodes. However, only one 
of the Order nodes will be executed. 

First, the Start node is linked to the Strep? node. This 
connection indicates the node to execute first. The first Flow 
Control node Fll is linked to both the Virus and Strep Order 
nodes. Doing so indicates that a decision will be made based 
on the results of an order filled in the first Order node. 

a. Click the Connection node tool 81e in toolbox 81 to 
select it. The pointer turns into a large arrow pointing 
up. 

b. Click once on the Start node, and then once on the 
Strep? node. An arrow appears between the two, indi- 
cating the order of the work flow. The Connection tool 
remains selected until a user selects another tool. So, a 
user can go ahead and make the other connections. 

c. Click the Fll node and then click the Virus node. 

d. Click the Fll node and then click the Strep node. 

e. Click the F12 node and then click the Exit node. 

f. Click the F13 node and then click the Exit node. 

g. Unselect the Connection tool by either clicking the 
Connection tool again or by selecting any other tool. 

The template having the connections is shown in FIG. 19. 

After making these connections or links, Flow Control 
node Fll must be edited to include the rules that govern the 
branch taken during patient charting. 

10. Connections 

As seen above, connections indicate relationships 
between nodes in a template. There are three types of 
connections: Order Results, Process Flow and Information 
Flow. Each type of connection is represented differently to 
help a user understand the relationship it represents. 

a. Order Results 

These connections are illustrated with double lines and 
indicate the relationship between orders and their corre- 
sponding results. FIG. 19a shows an order node with four 
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lab test orders. One of the orders in not available until some 
time later. The Order Results connections show which 
Result Nodes hold the results of the orders placed in a given 
Order node. 

As seen in FIG. 19b, whenever a triplet is placed into a 
template, the Order Node is automatically given one of these 
connections to the Result node. As with all connections, 
when nodes are moved around the template, the connections 
remain intact. 

b. Process Flow 

Process Flow connections are created using the Connec- 
tion tool 81c from Toolbox 81 described above. 

c. Information Flow 

These connections make order results from one triplet 
available to the rules in another triplet. They are illustrates 
in a template with a single line between a Result node in one 
triplet and a Flow Control node in another triplet, as seen in 
FIG. 19c. 

The connection is created using the Connection tool the 
same way Process Flow connections are created. A user 
creates these connections when a rule needs to reference the 
results of an order completed in a previous step in the plan. 
The example in FIG. 19c shows an Information Flow from 
the Result node in the "has. fever?" triplet to the Flow 
Control node in the "Fever" triplet. 

11. Programming the Row Control Nodes 
A Row Control node may be connected to two or more 
Order nodes, but only one of those Order nodes will be 
executed. Each Flow Control node contains a set of rules 
that determine which Order nodes will be executed in the 
next step of the template. A user defines the rules by creating 
simple expressions that reference the results of completed 
orders or other variables available in the template. 

a. Double-click the flow control node FU. The Flow 
Control Node dialog box 200 appears, as shown in FIG. 
20, listing two rules. Each branch in the template is 
associated with a rule. The rule indicates the Order 
node executed when the rule is satisfied and the branch 
is taken. The first rule in the list is the default rule. It 
is taken when all of the order results are available and 
no other rule is satisfied. In this example, the default 
branch leads to the Virus node. The orders in the Virus 
node are placed if the second rule is not satisfied. If the 
second rule is satisfied, the orders in the Strep node are 
placed. 

b. Click the second rule (If ( ) GOTO Strep . . . ) in the 
Row Control Node dialog box 200, to select the second 
rule. Since the rule for the Virus branch (the default) is 
satisfied only if the rule for the Strep branch is not, the 
second rule is edited first. This rule is edited using the 
Rule Editor dialog box 210 shown in RG. 21. 

c. Click Edit Rule 201, as shown in FIG. 20, to edit the 
contents of the currently selected rule. In general, rules 
contain expressions that reference the results of orders. 
The file folder tree in the lower left corner of the Rule 
Editor dialog box 210 contains all of the order result 
values that this Row Control node can reference. The 
result of the expression must be a logic value, i.e., 
TRUE or FALSE (or positive and negative). 

d. Double-click the Rel folder in the Rule Editor dialog 
box 210. Then double-click the Strep folder, the Test 
folder, and Value. A second rule has now been created. 
It appears in the scroll box 215 next to the word "If \ 
A user can read the files as follows: "If the result of the 
Strep test value is positive (meaning the result is 
positive) then follow the procedures in the Strep Order 
node." Since there are no other branches, a user can 
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also read in the following: "Otherwise, follow the 
procedures in the Virus Order node." Notice that Result 
node name, "Rel" in this case, is replaced with the 
keyword "THIS." The keyword "THIS" indicates the 

5 rule references the results of an order in this triplet. A 
user can manually replace "THIS" with "Rel" if a user 
wants to limit the rule to reference only the results in a 
node named "Rel". If a user leaves it referencing 
"THIS", the rule can be copied into the library and used 

10 in another template without change. The result is the 
same during patient charting whether the reference is 
prefixed by "THIS" or "Rel," However, if a user wants 
the rule to reference results of an order from this node 
or a previous node in the patient's plan, a user can 

15 replace the keyword "THIS" by the keyword "LAST". 
A user can simply replace the text in the rule editor 
field, or select "THIS" in the rule editing field, click the 
"Positional . . ." button 211 on the rule editor, and 
choose LAST from the list. If the order is not present 

2Q in this triplet, a rule specifying "LAST" will reference 
the most recent order results. 

e. Next, the probability that the results of the Strep test 
will be positive must be set. In general, the probability 
values are set based on experience, studies, or metrics 

25 gathered over time. For this example, click the At 
Probability drop-down arrow button 213 and select 10 
as the percentage. 

f. Click Done button 212 in the Rule Editor dialog box 
210. In the Flow Control Node Detail dialog box 221 

30 shown in FIG. 22, notice that the first rule automati- 
cally changed based on the second rule. Since the 
probability that the Strep test will return a positive 
result is about 10%, the probability that the sore throat 
is due to a virus is 90%. 
35 g. Click OK button 220 in the Flow Control Node Detail 
dialog box 221 to close it. 
A user must have enough rules to cover all of the branches 
out of the Flow Control node. Because every Row Control 
node contains a default rule and may contain additional 
40 rules, the number of rules is always one less than the number 
of branches. Thus, if a node has four branches, it must also 
have three rules. In this example, a user only needs to enter 
one rule. 

Note that even though the default rule is created, a user 
45 can still set the default rule. However, because the definition 
of a default rule is that it will be used when no other rule 
applies, the rule put in the default rule will not be evaluated 
as criteria for using the rule as long as it is the default. An 
option is available to change the rule to a non-default rule. 
50 At this point, the rule will be evaluated. 
12. Ongoing Order 

Ongoing orders are orders which are repeated 
periodically, or run continuously, until certain criteria are 
met. Ongoing orders may be selected from Ongoing Order 
55 button 128 in FIG. 12. An Ongoing Order Strep with result 
node R2 and Flow Control node D2 is illustrated in FIG. 
22a. Edit Order window, a special version of the Rule Editor 
window is displayed, as illustrated in FIG. 22b, The unique 
characteristic of this version of the Rule Editor, is the Repeat 
60 and Run buttons in the top left-hand corner. 

By clicking the Repeat button the order is repeated 
according to the rules specified in this window. 
When the Repeat button is selected, the label above it 
• reads "Repeat Until," and the field labeled "Next Starting" 
65 and "Number of lets a user further define the repeating 
order. The field labeled "Next Starting" indicates the date to 
start the next repetition of the order. A date or work shift is 
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entered in this field. The field labeled "Number of indicates 
the maximum number of times the order is to be repeated. 
The option arrow next to the field is clicked to enter a 
multiple of five, or any number greater than zero may be 
typed. 

The Run button is clicked to indicate the order is to run 
continuously until the specified rules are met. When the Run 
button is selected, the label above the Repeat button reads 
"Run Until," and the "Next Starting"0 and "Number of 
fields are replaced with the <r With Medicine" and "At Rate 
(ml/minute)" fields to help a user further define a continu- 
ously running order. The field labeled "With Medicine" 
indicates medication that is to be given in combination with 
a specified treatment. The field labeled "At Rate (ml/ 
minute)" indicates the speed that the dose of the medicine 
should be administered. For example, a user can create an 
ongoing order specifying a base IV solution and indicate the 
specific medication added in the "With Medicine" field (e.g., 
Potassium) and a flow rate of 1 ml/minute. 

A user specifies the conditions when the Ongoing order is 
to be discontinued in the scrollable field beside the Repeat 
and Run buttons. The discontinuation conditions are speci- 
fied as a logical expression. 

Some keys on the right hand side are gray. These keys are 
not applicable to this window. The rest of the keys are 
common to all the rule editors. 

13. The Plan Node 

The Plan node provides a way for users to create a 
template that branches into another template. The Plan Node 
acts as a special type of exit node because it causes the 
current template to exit and the new template to begin. 

FIG. 23 illustrates a template containing Plan nodes 
according to the present invention. This is an example of a 
template that might be used by an emergency department 
screening nurse when a patient comes to the emergency 
department complaining of a sore throat. The first step in the 
template in FIG. 23 specifies an assessment of the patient's 
throat, and any relevant history, to determine whether the 
patient should be treated for a bacterial or viral throat 
infection, or throat injury. Based on this decision, the patient 
is started on one of two templates. Before adding a Plan node 
to a template, first create the templates behind the Plan 
nodes. Since each Plan node is a complete template, a user 
will need to follow the procedure for creating a template to 
establish the content within each Plan node. 

A user can insert a Plan node in the template as a place 
holder for the template before it is completed. A Plan node 
may be placed into the template using the Plan node icon io 
the toolbox with the other node types, for example, order 
triplets and the exit node. 

Assuming a user has already created a template for a Plan 
node, the following steps place the Plan node into a new 
template. 

a. Click the Plan node icon in the toolbox, move the cursor 
to the desired position in the template and click the 
mouse to place the Plan node into the template. 

b. Select the empty Plan node and choose the Name 
option from the Edit menu. This brings up the Plan 
Node Detail dialog box 350 as shown in FIG. 24. 

c. If the template has been previously created and saved, 
double click the name of the desired from the list of 
available templates. This attaches the Plan node to an 
existing template. A user may enter a description and 
assign the Plan node to a department. 

d. Click OK button 351 to close the dialog box. 

At this point, the Plan node is tied to another template. If 
you double-click on the Plan node, the template is brought 
up and you may edit it. 
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14. Saving the Template 

To save the template, the Save from the File menu may be 
chosen using the default name given by ARAXSYS™ 
Solution. Or the following can be done: 

a. Choose Save As from the File menu. 

b. A Save As dialog box will pop up for a user to type the 
name of the template. Make sure the file is in the "data" 
subdi rector in the director where icm.exe is located. 

c. Click OJC 

C. Building a Template Flow Chart 
FIGS. 25A-25B illustrate the logic flow in building a 
template according to the present invention. Objects, meth- 
ods and attributes described in FIGS. 25A-25B arc 
described in detail below. A user first needs to decide the 
time slot scheme to be implemented in logic block 500. A 
time scale dialog box is then displayed, allowing the user to 
select the scale and unit in logic block 501. The correspond- - 
ing template object (for example, template object 348 in 
FIG. 27) is updated to reflect the new time scale and time 
slot size in logic block 502. Based upon the selected time 
20 slot scheme, the number of time slots are determined and 
labeled in logic block 503. The window reflects the new 
selection. In logic block 504, a user selects the node icon in 
the toolbox and drops the icon next to the start node. A triplet 
is then drawn in logic block 505. In logic block 506, an 
instance of the node object is created. The node object is 
then added to the template object list (node_Jist 371 in FIG. 
27). Further, the associated attributes of the node are created 
and a unique name may be determined for the node of 
triplets. If this is the last node before the Exit node, the logic 
flows to logic block 507. Otherwise, a user may select 
another node in logic block 504. A user connects the nodes 
in logic block 507. In logic block 508, a node is selected by 
the user to fill its contents. An Order node window will be 
displayed with the current order contents from the node 
object. In the case of a new node, the display will be empty. 
In logic block 509, the library order item object (for 
example, order 358 in FIG. 30) is traversed to list all orders 
in the library in the order content window. In logic 510, a 
user selects the order items to be added to the node object. 
Further, attributes of the order are added. With each order, an 
entry in the result node object (Result node 359 in FIG. 27) 
is created and the status of the result item is linked to the 
control node which contains the rule (If Rule 353 in FIG. 27) 
object via the information flow link list. The name (Name 
399 in FIG. 27) of the node may be changed in logic block 
511. The uniqueness of the name is verified by comparing all 
the names in the node list of the triplet object before the 
change becomes effective in the object and reflected on the 
screen. A flow control node is selected to create rules for 
branching in logic block 512. A search for the destination 
node in info_destination_Jist which is connected to the 
flow control node is then carried out. The Flow Control node 
detail dialog box is then displayed. The flow control rules 
will be empty, except for the default rule. User will click the 
rule or the Edit Rule button to display the rule editor dialog 
box in logic block 513. The contents of the rule editor dialog 
box is constructed after all the result node objects connected 
to the flow control nodes are searched in the node_list of the 
triplet. The results which can be used to contribute to the rule 
is displayed in the rule editor in logic block 514. In logic 
515, the user creates the rule and enters the percentages. The 
rule is then stored in the (Expr. 354 seen in FIG. 27) object 
and the percentages are then added to derive the percentage 
for the default rule. The percentages are then displayed on 
the screen. If no other nodes need to be filled, the exit node 
is selected and placed in the template in logic block 516. 
Otherwise logic block 508 is performed. 
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D. Costing 

FIG. 25c illustrates the logic flow of determining the cost 
of various healthcare treatments according to the present 
invention. The cost of various treatments is initialized at the 
Start node in logic 600. A search for the next destination 
node, which has not yet computed cost, using the node list 
371 and info_destination in Result node 359, as seen in FIG. 
27, is done in logic block 601. A total cost is determined by 
adding all item costs of the order node in logic 602. Each 
order object has an attribute object which contains associ- 
ated costs for each order item. A running cost (i.e., new 
accumulated cost) is determined in logic 603 by adding the 
selected node cost (including all order item costs) which is 
multiplied by the percentage associated with the path which 
leads to this node to the current accumulated cost. A deter- 
mination is then made whether this node is the last node of 
a path. That is, if there is any destination node of this node. 
If this node is the last node, the present order node object is 
retrieved in logic 604, so we can use the same logic to 
compute the cost of the next path of the present node. 
Otherwise, the flow control node is followed in logic block 
605 in order to determine the cost of the next destination 
nodes. 

III. ASSIGNING A TEMPLATE TO A PATIENT 

A template may be assigned to one or more patients. 
When a template is assigned to a patient, it becomes part of 
the patient's plan. The patient's plan is a collection of all of 
the templates that have been assigned and possibly tailored 
to the specific patient. Once a template is assigned to a 
patient, the template may be modified or executed. 

To assign the Clinic template to a new patient: 

a. Click the Plan Administrator button on the toolbar 81 
shown in FIG. 8, A template may be assigned to 
patients from the Go To menu or click the Assign 
Template to Patients button on the Main Directory as 
seen in FIG. 7. The Plan Assignment dialog box 230. 
appears and lists current patients and stored templates. 
FIG. 31 illustrates the Plan Assignment dialog box 
according to the present invention. 

b. Click the template name to select the template. 

c. Click the patients name. 

d. Click Assign Template 231. 

e. To add a new patient, type the patient's name in the 
New Patient Name Field 232, press the Tab key to 
advance to the next field 233, and type the patient's 
social security number. Then click Add New Patient 
button 235. The patient's name appears within the 
Patients list on the left as shown in FIG. 32. 

f. Click done button 234, The patient assignment is 
recorded and the patient assignment window closes. 

If a completed plan is under a patient's name, GUI asks 
if a user wants to archive the plan. If a user answers "yes," 
the plan is saved in the patient's archive directory for later 
review and the name of the archived plan is no longer listed 
in the existing patient tree. 

IV. PATIENT CHARTING 

As described above, there are two different views avail- 
able when delivering a patient's plan: Flow Chart view or 
Chart view. The Flow Chart view is ideal for simulating plan 
delivery in order to ensure the correctness of a new template. 
The Chart view is more suited for delivering care to a real 
patient and more closely resembles patient charts. 

A. Charting in the Flow Chart View 

A template assigned to a patient becomes part of the 
patient's plan and can be delivered. During the delivery 
operations, a user enters the results of tests and changes the 
status of orders when the order has been completed (i.e., 
filled). 
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To deliver a patient's plan using the Flow Chart view: 

a. Choose Main Directory from the File menu to see the 
Main Directory window as seen in FIG. 7. 

b. Click the Assign Templates 71 to Patients button to see 
the Plan Assignment window. 

c. Double -click the patient's name in the patient list to see 
the templates that have been added to the patient's plan. 

d. Double-click the template name beneath the patient's 
name to see that template in the Flow Chart view. At 
this time, the Chart view exists, but is hidden. By 
dropping down the window splitter the Chart view 
is revealed. 

FIG. 32 illustrates how to open a patient's plan according 
to the present invention. Specifically, double -click myelin - 
ic.pln folder presents "Jim Sanders" Flow Chart view as 
shown in FIG. 33. In this view, colors are used to distinguish 
between plan steps that (1) have already been completed, (2) 
are presently active, and (3) have not been completed. 

A user can change the colors using the Color Preference 
command from the Options menu. 

Nodes marked active contain orders that have been placed 
and are awaiting results. There may be more than one active 
node in the plan at one time, but the right most active node 
is where the next branching decision is made in the plan. 

Each time an order result is entered, the rules in the Flow 
Control node are evaluated to see if enough information is 
available to branch to the next step in the plan. When all of 
the order results specified in a rule are entered, the rule is 
evaluated. If the rule is satisfied, the rule will become active 
and take the plan down the corresponding path. 

e. Double -click the Rel node to display the Result Node 
Detail dialog box 260 in FIG. 34. It lists work orders 
and their completion status. At this time, none of the 
work orders have been completed and all are marked 
"Not Done." 

f. Double-click the first item in the Order Status dialog 
box. The Result Form dialog box 270, as illustrated in 
FIG. 35, appears. In this dialog box, a user enters values 
to indicate the results of tests and change the comple- 
tion status of work orders. The test results are entered 
in the Value column. 

g. Click in the value column 272 of the Test row. Type 
FALSE or N for negative (the default value), or TRUE 
or P for positive. For this example, type P. 

h. Press enter or select another field. 

i. Click the down arrow 271 in the Status box and change 
the status from Active (not done) to Done. 

j. Click the Done button 273. The status has now been 
updated for this procedure, it is listed as Done in the 
Result Node Detail dialog box as shown in FIG. 36. 
The Vitals order remains Not Done. 

k. Even though the Vitals order remains Not Done, Click 
OK 281 to close the dialog and view the plan flow 
chart. 

The GUI, according to the present invention, automati- 
cally determines the next step in the care flow based on the 
results of the strep test even though the vitals were not 
completed. The Strep Flow Control node Fll in FIG. 23 is 
completed (shaded dark gray) and the Strep Flow Control 
node F13 in FIG. 33 is active (green). 

In this example, both the Rel and Re nodes are active 
(green) and awaiting result values. This is because the 
branching rule in the Flow Control node does not include 
any results from the vitals. If a user wants the branching 
logic to consider one or more of the vital statistic values (i.e., 
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temperature to check for a fever), a user can modify the rule 
to reference the vital value(s). Even though the vitals are 
generally taken in advance (probably by a nurse even before 
the physician sees the patient and orders the strep test), and 
are normally available before the strep test results, this 
example demonstrates that the rules become active as soon 
as the results that they depend on are available. 

1. Update the results of the Re3 orders in the same way 
you completed those for Rel. 

At any time during charting, a user can open a Result node 
or Flow Chart Node to view its content after it has been 
completed. A user can also choose to chart from the View 
menu to see all the past activity in this plan at a glance. 

1. Charting Into a Plan Node 

When a user takes a branch down a path that leads to a 
Plan node in the patient's chart, the Plan node is highlighted 
in both the Flow Chart and the patient Chart views as shown 
in FIG. 37. The Plan node indicates it is Not Done 291 until 
you double-click on this step in the plan (either the Plan 
node in the Flow Chart view or the column entry in the 
patient Chart view). At this point, the Plan node is set to 
Done, indicating you have entered the Plan node. 

When a user charts a patient plan into a Plan node, the 
previous plan is discontinued and the new plan is started. 
The view of the new plan will be used to continue charting. 
Whenever a user leaves a plan, the user is presented with a 
dialog box that asks if a user would like to archive the plan. 
It is generally a good idea to not archive the old plan when 
entering a Plan node. 

2. Manually Executing a Plan 

There are two ways to manually direct the execution of 
the plan: force the plan to branch, and reexecute a step in the 
plan. 

To force the plan to branch down a specific path, regard- 
less of the result values and the flow control rules, a user 
opens the right-most active Row Control node, select the 
rule governing the desired path, and click the Execute 
button. The plan will branch down the specified path. 

To reexecute a step in the plan, for example, if treatment 
has gone down one path and a user needs to back up the plan 
to go down another path, a user reexecutes the previous plan 
step. Click the order node to go back to and either click the 
Execute button on the tool bar 81 or choose Execute option 
from the Mew menu. The plan will back up to the selected 
node making it the right-most active node. 

B. Charting in the Patient Chart View 

Charting a patient using the Chart view is very much the 
same as charting in the Flow Chart view. 

a. On the Main Directory seen in FIG. 7, click Chart 
Patients button 72. A user may also choose Go To Chart 
Patients menu on the tool bar 81. 

A summary of all the patients is displayed. This example 
shows one patient and one plan (the clinic plan that treats 
strep throat). 

b. Click a patient's name to display the patient's chart. 
When entering the patient chart, the Flow Chart view is 
usually hidden. While the Chart view is displayed, the 
window splitter can be used to reveal both views. 

In the Chart view as shown in FIG. 38, each step in the 
patient's plan is represented as a pair of columns. The 
content of the Order node is shown in the first column. The 
corresponding order status is shown in the second column. 
Each step is labeled at the top with the step name and the 
time slot encompassing the step (in the example, time slots 
have been disabled so the step name is blank). The columns 
proceed from left to right by time slot. 

The column with white cells 301 or 302 represents the 
active step and is ready to be charted. The gray columns to 
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the right of the active column show the most probable path 
through the plan. The probability values associated with 
each rule determine the most probable path through the plan. 
In this example, the Vims path is the most probable, 
s c. Double-click the white cell 301 to the right of the Strep 
order to see the Results Form dialog box. Enter the 
results of the strep test (P for positive) and click the 
Done button to mark the work order "Done" as in 
charting in the Flow Chart view example above. The 
io effect is the same; the plan branches down the Strep 
path. Also, as in the Flow Chart example, the Vitals 
results (Rel) are left active (since they have not yet 
been entered) and the results of the strep orders become 
active as shown in FIG. 39. 
15 d. Enter the required results for the Strep orders to 
complete the plan. 
To see the Flow Control node content on the chart, choose 
Show Chart Details from the Options menu to show the 
rules. An active rule will contain Bold characters. When a 
20 user closes the chart or switches to a different module, the 
GUI prompts a user to save the state of the patient's chart. 
If a user decides not to save the present state of the plan, it 
returns to its previous state; that is, the state the plan was in 
before you began charting. Therefore, no changes will be 
25 reflected the next time it is opened for charting. 
1. Charting Into the Plan Node 

A user may similarly chart into Chart view, as described 
above. Except when a user decides to archive the old plan, 
the order result information is not listed in the Chart view, 
30 while not archiving will leave the information in the Chart 
view as part of the patient history data. 

C. Flow Chart and Chart View Logic Flow Diagram 
FIG. 40 illustrates a logic flow diagram for displaying a 
Flow Chart and View Chart according to the present inven- 
35 tion. 

In logic 800, a determination is made whether a user 
moves the window splitter up or down. If the user and is 
moved the splitter down, a determination is made in logic 
block 801 to display a Flow Chart view of a patient plan. 

40 Accordingly, in logic 802, a time slot object (real time slot 
363 as seen in FIG. 27) from the plan object (plan object 360 
as seen in FIG. 27) is obtained. The screen is updated with 
a time scale and unit size according to the time slot object. 
The node list in the plan searched for the next active node 

45 in the plan object obtained in logic 803. In logic block 804, 
if the state attributes of the node object is checked to see if 
it is executed. The node is then colored with a user-selected 
color if the state of the node is executed. A determination is 
made in logic block 805 whether the node is a destination of 

50 a previous node. If the node is a destination of a previous 
node, an arrow is drawn between the parent node and this 
node. A determination is then made whether the node is the 
last node in a plan object. If the present node is not the last 
node, the logic loops back to logic block 803. Otherwise a 

55 Flow Chart view is drawn. If a user selected the view chart, 
the logic proceeds to logic block 806. A table with pre- 
defined numbers of rows and fonts is drawn. The lime slot 
object is then obtained from the plan object in logic block 
807. The real time of each slot is also obtained and used as 

60 a label for each column. A determination for the most 
probable path is also determined by examining the prob- 
ability value of each path in logic block 808. Data for the 
next order of the selected node is then obtained in logic 
block 809. This data is filled in the cells of the next available 

65 column. The status from the corresponding result node is 
then obtained in logic block 810, The status of the items in 
the result node in the cells of the next available column are 
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then displayed. The status of the node is then checked in may contain several values that describe the plan element, 

logic block 811 and colored accordingly. Finally, a determi- These values are separated with commas and arranged in 

nation is made whether the last node in the view chart form columns. This comma-separated value format is easily read 

is the present node. If a present node is not the last node, the bv mo ^ 1 spreadsheet and data base software, and other 

logic loops back to logic block 808. Otherwise, the view s analysis programs, 

chart is displayed. c - Usm 8 Analyze Patients 

V CUSTOMIZING A TEMPLATE OR PLAN ARAXSYS™ Solution's Analyze Patients module also 

If the patient's treatment isn't covered in a generic allows users ito extract data ifrom a ^t^plate and convert it to 

template, a user can copy an existing template similar to one ^ andard format that ° ther WIND0WS ® programs can 

needed and modify it to suit a specific patient. A user can 10 * . , , ' A , „ . , „ , , ». . 

customize a template by adding nodes, deleting nodes, or a " ^ ^ ze PaU ^ U bu,,0 ° ™ f T.. , C J"" 

modifying node contents in a Flow Chart view. Dlrector y «™ dow f * how ? in FIG. 7. A dialog box 

A Deleting a Node opens and displays the list of patients a user has entered 

Deleting any of the nodes in a triplet removes the entire < from Patient Assignment window), 

triplet. Exit nodes may be deleted separately and Start nodes 15 b * Qlck P atlcnt name t0 scc a ^ of the templates 

may not be deleted. integrated mto the patient's plan. 

B. Modifying the Clinic Template c - From ^ l^t, select the plan template a user wants to 

Suppose a user has a patient who may have Strep throat export, 

but also requests a prescription for a preexisting condition d. Choose the desired data format and click the Export 

such as migraine headaches. A user needs to modify the 20 button. A user will be prompted to enter a file name for 

Clinic template to include a prescription for Tylenol III. the converted data file. 

To modify the Clinic template: e. To input the data into the other application, open that 

a. Open the Clinic template that was previously assigned application and use its Import command. This com- 
to a patient. mand is usually on the File menu. 

b. Double-click the Strep? node to open the Orders dialog. 25 Avsct c » n ^ P rint converted data using the "Print" 

. , ^ , i , 1*1 option on Export dialog box. The plan data is printed in a 

c. Click Add button 117 in the Orders node detail dialog £ ormat 



box shown in FIG. 11. 



VII. MERGING HEALTHCARE PLANS 



d. Double-click Meds, Pharmacy, and PO_Pain_Meds_ A Merging Plans 
TylenoLJII ($10.00) in the Command list of the Add 30 a new pat i ent is enrolled and placed on a treatment 
Orders dialog box 122 shown in FIG. 12. protocol, for example, the first template is assigned to a new 

e. Click Place Order button 127 and then click Done patient and the template becomes the patient's master plan, 
button 124, It is often the case that the patient will need to be placed on 

f . Click OK button 113 in the Orders dialog box 110. a new, possibly unrelated, treatment protocol, such as started 
The number above the Strep and Rel nodes change to 3 35 on a new template, while the first plan is still in effect, such 

indicating that there are now three work orders associated as a pregnant woman on a prenatal plan with a sore throat, 

with these nodes. To handle these cases, a user simply assigns a new, addi- 

The same set of operations to modify the protocol during tional template to the patient, 

the plan delivery phase may be used in the charting/walk- At this point, the physician has to decide whether to merge 

through module. In an embodiment, the customization can <to the new template with the master plan, or start the template 

only be done in the Flow Chart view and the toolbox is as a separate plan in parallel with the master plan. The 

hidden by default in plan delivery mode. default behavior is to execute the two plans in parallel, but 

VI. EXPORTING PATIENT PLAN DATA this may be undesirable if the orders in the new plan conflict 

The GUI, according to the present invention, provides with the orders in the master plan, 

several ways to export data gathered during charting. DDE 45 When there is a chance of orders conflicting between 

(Dynamic Data Exchange) allows GUI to notify another plans, a user should merge the new plan into the master plan. 

Windows application when orders are placed and rules are The merge process will allow a user to resolve the conflicts 

active. A patient plan may be exported in a format that can and plan out a treatment course that covers both conditions 

be read by applications such as Microsoft's Excel spread- effectively, 

sheet. FIG. 41 illustrates a plan element, exported from the 50 B. The Merge Process 

"clinic.pln" and imported into an Excel Spreadsheet. A The merge process begins when a template is assigned to 

modified patient plan can also be exported as a generic a patient that is currently on an active plan. This section 

template. explains the merge process using a simple example scenario 

A. Using DDE to illustrate each step. In the scenario, Mr. Sanders is having 
In the Options menu, the commands DDE Enabled/DDE 55 his hip replaced according to the hip .pin template. Presently, 

Disabled, allows a user to export the data in the Result node Mr. Sanders is on day four of the hip replacement plan and 

to other applications that support DDE. is being treated for a fever that has developed after surgery. 

For example, an Excel spreadsheet can contain macros On this day, Mr. Sanders manages to hurt his wrist on the bed 

that will read the DDE data and enter them into various cells rail while reaching for his book. His doctor assesses the 

in the spreadsheet First, start Excel and open the spread- 60 swelling and decides to place him on wrist trauma protocol 

sheet. Then start the GUI Chart Patient module and choose designed specifically for patients with an intravenous 

DDE Enabled from the Options menu. When a user enters . ("IV"), that is, the protocol prescribes IV medications 

data into the results forms, the data is also sent to the Excel instead of oral medications. Since the wrist trauma protocol 

spreadsheet. will likely impact the hip replacement plan, Mr. Sanders' 

B. ASCII Export Format 65 doctor decides to merge the wrist plan with the hip replace - 
When a plan is exported as an ASCII format file, each ment plan. In order to merge the plans, the following steps 

element in the plan is written on a separate line. Each line are completed: 
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a. First, assign the wrist trauma template to the Mr. 
Sanders master plan — the hip .pin he has been on for 
several days. Click the Assign Templates to Patients 
button 71 from the Main Director shown in FIG. 7 to 
bring up the Plan Assignment Window shown in FIG. 
42. 

FIG. 42 shows how the Plan Assignment window looks 
just before the wrist.pln is assigned to Mr. Sanders. The 
wrist.pln template and Mr. Sanders are selected. 

b. Click the Assign Template button 900. The wrist trauma 
plan, wrist.pln, is now listed beneath the hip replace- 
ment plan, hip. pin, as shown in FIG. 42a, 

c. Double-click the wrist.pln line listed beneath Mr. 
Sanders' name in the patient list. Doing so brings up the 
wrist trauma plan, wrist.pln, in the Flow Chart view. 
The first triplet is highlighted to indicate it is the next 
step in this plan. 

d. Maximize the wrist.pln window and pull down the 
splitter bar to divide the Flow Chart view in half. The 
splitter bar is the thin, raised gray bar just below the 
Flow Chart view window title bar. This reveals both the 
wrist trauma plan and the master plan, namely the hip 
plan in this example, as shown in FIG. 43. 

When the plan is first opened, it shows both plans starting 
from the first time slot. When plans are merged and have 
different time slot settings, the time slot setting from the plan 
with more narrow focus.shorter duration is selected for the 
integrated plan. For this reason, it may be necessary to adjust 
placement of nodes in the plan that changed to make sure 
nodes are in the proper time slots. In this example, both 
plans have time slot settings by day and this adjustment is 
not necessary. 

e. Before a user can merge the wrist plan into the active 
hip plan, a user needs to move the wrist nodes to day 
four where the hip plan is presently active. Select the 
Order Node in the first triplet in the wrist plan and 
choose Select All Nodes Right from the Edit menu. 
This selects all of the wrist plan nodes. Now, drag the 
nodes to the right until the first triplet is positioned in 
day four and the second set of triplets is positioned in 
day five. Next, scroll the hip plan to the right until both 
plans are aligned by time slot. Adjust the scrolling so 
that a user can see all of day four and five. When a user 
is done, the Flow Chart view window looks similar to 
FIG. 44. 

The nodes in the wrist plan are merged into the hip plan 
at day four because Mr. Sanders is presently on day four of 
the hip plan when the wrist injury occurs. In this example, 
the merge needs to take place on day four. But in general, 
selecting a time slot may not be apparent because more than 
one time slot may be active in a plan. 

Nodes in the next plan step become active once a rule is 
satisfied in the current plan step. Rules often only reference 
one or two order results out of all that may be available in 
the triplet. If one of two orders are filled and show results 
that trigger a rule, the plan may branch to the next step 
before some of the other orders are completed. When this 
happens, two steps become active in the plan. The outstand- 
ing orders may be filled in the previous step and the new 
orders may be filled in the newly activated step. But, since 
the plan has moved to a new step, the rules in the previous 
step are no longer checked; they no longer direct the plan 
flow. 

The right-most active triplet is the leading active triplet 
and is the site of the next branch in plan. Nodes in the second 
plan may not be merged into time slots before the leading 
active node in the master plan. A user cannot merge a node 
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before this triplet in the master plan, because the new node 
would not be able to participate in the branching decisions. 

Since nodes are merged on a time slot by time slot basis, 
a user needs to reposition the nodes to make sure that no 

5 more than one plan step is present in each path in the day 
four and five timeslots. A user cannot have two or more 
triplets in a sequence, or a triplet followed by an exit node 
in the same time slot. Since the second step in the wrist plan 
contain triplets in multiple paths (the triplets are on separate 

10 paths), it is correct to leave these triplets arranged vertically 
in the same time slot as long as they are in separate branches 
of the plan. 

f. Now that all of the nodes have been positioned properly, 
a user is ready to merge the first (active) step in the 

15 wrist plan with the active step in the hip plan. Select the 
order node in the wrist plan and choose the merge 
option from the Edit menu. FIG. 45 shows what the two 
plans look like after merge (and some rearrangements 
done for cosmetic reasons). 
20 The Assess_Wrist triplet is merged into both paths in the 
hip plan. Since no triplet is present in the upper path (the one 
that would have been taken had Mr. Sanders not developed 
a fever after surgery), the Assess_Wrist triplet is inserted in 
its entirety (minus rules in the Flow Control node). In the 
25 second path, the orders from the Assess_Wrist Order node 
are added to the orders in the Fever_Labs. Order node. 
Notice that before the merge the Assess_Wrist node con- 
tained three orders and the Fever_Labs node contained six 
orders, but after the merge the Fever_Labs+Assess_Wrist 
30 node only has eight orders. This is because both nodes 
contained the same order for pain medication. Duplicate 
orders are removed during a merge. 

The rules from the Assess___Wrist triplet are left in a 
solitary Flow Control node as a place holder until the next 
35 step in the plan is merged. 

g. Merging the second step is similar to merging the first 
step. Select either of the Order Nodes in the wrist plan 
and choose the Merge option from the Edit menu. After 
rearranging the nodes a little and opening the hip plan 

40 all the way, the resulting merge appears as in FIG. 46. 
As in the merge of the first step, orders were combined 
and duplicates were removed. This time, however, the rules 
from the previous step were merged into the Flow Control 
nodes to reflect the branch in the wrist plan between treating 

45 a fracture and treating a sprain. 

This simple example illustrates the basic steps, required to 
merge two plans, but this simple example does not highlight 
any conflicts that may arise during a merge. The merge 
removes duplicate orders, but it does not remove similar 

50 orders. In the example, the two plans prescribed the same 
pain medication, but in general, that may not be the case. 

After the merge, a user needs to review the orders to make 
sure the combination of orders still makes sense. If another 
pain medication had been prescribed in the wrist plan, the 

55 result of the merge would contain two orders for similar, but 
different, pain medications. Since the pain medications 
prescribed for the hip plan are probably well-suited to 
handle any pain from the wrist injury, a user would probably 
want to remove the second pain prescription that originated 

60 from the wrist pain. 

There are several types of conflicts that may appear after 
a merge that must be addressed. Medications may conflict 
with one another (e.g., two similar, but different pain medi- 
cations are present). Orders may need to be delayed based on 

65 the new condition (e.g., it is impossible to complete the 
combined set of orders in the designated time slot). New 
orders may need to be added in addition to the sum of the 
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merged orders (e.g., since Mr. Sanders injured the wrist that 
had the IV site, the IV site needs to be moved to the other 
arm). In addition to these conflicts, there are numerous 
unforeseen conflicts that may occur when orders from 
unrelated templates are combined. Users can specify the 
rules to resolve these conflicts and store the rules in the 
library. 

The example scenario indicates several of the adjustments 
that must be made to the two plans before they are merged, 
but there are a few other constraints that must be addressed 
in the general case. A user must properly arrange the nodes 
in the two views so that they meet with following criteria 
before merging the triplets in a time slot. 

First, both plans must have the same time scale setting. 
They must be both by day or by shift or by visit, etc. If the 
two plans have different time scale settings, change the time 
scale in the plan with the more broad time scale setting. For 
example, if one plan is set to days and the other is set to 
shifts, a user should change the plan that is set to days to a 
plan set with shifts. When the time scale setting is changed 
from days to shifts, a user should reposition the nodes into 
the desired shifts within the desired day because the nodes 
do not move when a user changes the time scale setting. 

Second, two or more triples may not be in a sequence, or 
a triplet followed by an exit node in the same time slot. Since 
a single plan step can contain triplets in multiple paths, or 
triplets may (and probably will) be arranged vertically in the 
same time slot as long as they are in separate branches of the 
plan. 

Third, new orders may not be merged into previously 
executed steps in the master plan. Nodes in a second plan 
may not be merged into time slots before the leading active 
node in the master plan. 

Fourth, nodes may not be merged that have already been 
completed. If a user has been working with the second plan 
in parallel with the master plan (e.g., the user has not merged 
plans yet) and then a user decides to merge nodes, a user 
must start merging with the leading active node in the 
second plan. A user cannot merge fully or partially com- 
pleted nodes (i.e., a triplet with a few orders outstanding) to 
the left of the leading active node in the second plan. After 
merging the leading active node, a user can then merge 
nodes in the subsequent time slots, but each time slot must 
be merged in order from left to right. 

Error messages are displayed if the plans do not meet 
these criteria. A user can fix the problem and try again. 

Once a user begins merging nodes, a user can stop at any 
time. Those nodes left unmerged will be maintained as 
parallel paths until they are merged. If the plan advances to 
one of these parallel paths and they remain unmerged, they 
can be charted in parallel. 

During the merging process, a user will probably need to 
move nodes around. There are several selection options 
under the Edit menu to help a user select a group of nodes. 
For example, a user can select a node, choose the "Select All 
Nodes Right" option from the Edit menu, and drag all of the 
selected nodes to the right. 

C. Merging Two or More Templates Logic Flow 

FIGS. 47 and 4&a-48e illustrate the logic of merging two 
or more templates. A user opens two templates to be merged 
in a Flow Chart view in logic block 950. The user arranges 
the two templates so that they correspond to correct time 
slots. An example of two templates to be merged which are 
aligned in correct time slots is shown in FIG. 48a. 

A merge object is constructed in logic block 951 and 
illustrated in FIG, 48£. P? and Q? represent flow control 
node rule expressions. For example, P? represents the rule 
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expression "If test result is positive ..." go to target order 
triplet A, otherwise target order triplet B. While Q? may 
represent the rule expression "If temperature is high ..." go 
to source order triplet 1, otherwise go to source order triplet 

S 2. The merge object consists of all combinations of Order 
nodes in the first template and second template. Each item 
in this merge object contains the source triplet order objects 
1, 2, the target triplet order objects A, B, and the new 
resulted triplet order objects called Al, A2, Bl and B2. Table 

10 960 illustrates the various combinations of obtaining the 
resulted order triplet objects, A top Flow Chart view of the 
in progress merge template is drawn using the merge object 
in logic block 952 and as illustrated in FIG. 48c. New order 
triplets, including Al, A2, Bl, and B2 are drawn combining 

15 the various order triplets, as shown in FIG. 48d. For 
example, a possible positive test result and high temperature 
would cause flow to be directed to new order triplet Al. 
Branches from these new triplets will also be drawn. The 
content of the new triplet order nodes (Al, A2, Bl, B2) will 

20 contain all orders belonging to the original order nodes (A, 
B, 1, 2), less the duplicated and content conflicting orders. 
Logic block 953 compares order items from order node 
objects and determines if duplicates or conflicts exist. The 
action or rule taken on duplicate orders can be stored and 

25 retrieved from a library item. In logic block 954, new arrows 
from the updated flow control node in the present time slot 
and the newly created merged triplets are drawn. In logic 
block 955, original triplets A and B are removed from the top 
Flow Chart view. Further, result nodes U? and V? are also 

30 removed from the lower Flow Chart view. However, the 
flow control node of the bottom plan remains in order to 
continue execution separately or for further merging. FIG. 
48e and logic block 956 illustrate the merged template 
according to the present invention. The node objects of the 

35 bottom template are not removed from the plan node. 
Information control connections between order triplets Al, 
A2, Bl, B2 and the lower flow control nodes are added 
internally (not shown in FIG. 48c) in order to allow for 
separate or parallel execution. 

40 D. Outcome and Limitations 

Every time a user selects the merge command, command 
and result nodes in the lower plan disappear. The number of 
items in the master plan node will increase by the same 
number which used to be in the lower plan. If there are 

45 multiple paths in the time slot in the lower plan (the merging 
plan), there will be new nodes created in the master plan to 
represent the merged plan. 

Nodes containing zero items may be created during 
merge. These "dummy nodes" are created to carry internal 

50 information that must be preserved after the merge. 

Flow control nodes in a time slot are not merged during 
the merge of this time slot. They are merged when the next 
time slot is merged. If a user chooses not to merge the rest 
of the plan, these nodes and the rest of the plan stay intact 

55 and the remaining plan is delivered in a parallel fashion as 
if there were two plans active simultaneously, A user can 
merge a few time slots and decide to postpone the rest of the 
merge by saving the plans using the Save command. 
There is no specific limit on how many plans a user can 

60 merge. However, a user must merge them two at a time. The 
Chart view always records the actions taken in all plans 
assigned to a patient 

Whenever a user assigns a new plan to a person, the 
present invention delects if any of the existing plans have 

65 been completed. If a plan has been completed, the GUI asks 
a user if the completed plan should be archived. A user 
should archive a completed plan unless a user wants to refer 
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to the information in the completed plan while charting a 
new plan. Archived plans do not appear in the Chart view but 
can be viewed separately with the Open command from the 
file menu. 

VIII. SERVER OBJECTS TO SUPPORT GRAPHIC USER 
INTERFACE (GUI) 

The graphic user interface according to the present inven- 
tion is implemented using object-oriented structure software 
design. An example of object oriented structure design is 
described in Object Oriented Design with Applications; 
Boocb, Grady, Benjamin/Cummings Publishing Company, 
Inc. (1991), incorporated by reference herein. A GUI server 
is implemented using objects and methods defined below. 
However, it should be understood that other software desiga 
principles and architectures could be similarly used to carry 
out the present invention. 

1. General Server Object Interfaces 

Every GUI server object 300 supports several standard 
interfaces. FIG. 26 illustrates the server object interfaces that 
may be mixed into any or all of the GUI server objects. For 
example, an order node may have a corresponding server 
object having the illustrated interfaces. FIG. 27 illustrates 
the relationship between various server objects according to 
the present invention. 

a. Standard Server Object Interface 

The standard server object interface is supported by every 
distributed object in the GUI server. Every object 300 has a 
Name 301, Attribute List 302, and Parent attribute 303. In 
addition, every server object contains a Propagate_Change 
method 304. 

(i) Name Attribute 

The Name attribute 301 is unique for the instance of the 
GUI server object in its context (e.g., a node in a plan, an 
order in a node, etc.). The Name attribute 301 will likely 
conform to the Name type expressed in The Common Object 
Request Broker: Architecture and Specification, Version 2.0 
("CORBA Standard") incorporated by reference herein. 

(ii) Attributes List Attribute 

The Attributes List 301 is a general set of name/value 
pairs associated with every server object instance. These 
attributes may be "well known" (e.g., expected to be 
present) or specific to the object class. Well known attributes 
include Category, Department, and Cost. In orders, attributes 
include results, order qualifications (e.g., drug dosage), and 
start and finish times. Attributes 302 may be referenced by 
rule expressions to determine the branch a patient takes 
through their plan. 

(iii) Parent Attribute 

Most GUI server objects are contained within some other 
object. The change notification scheme requires a given 
object to identify what changed at their level and then 
propogate a change notification up to their parent. The 
Parent attribute 303 keeps track of which object is currently 
the parent of a given object. Parentage can change over time. 

(iv) Propogate_Change Method 

A change notification scheme according to the present 
invention uses a chaining mechanism to specifically identify 
what changed in the GUI server data. When the change 
information is compiled, it is passed to all client applications 
that have registered for change notices. 

The change information is compiled into a stack object. 
The object that makes a change pushes an entry into the 
stack indicating what changed at their level. The object then 
invokes the Propogate_Change method 304 in the parent 
(through the Parent attribute 303). The parent pushes an 
entry into the stack indicating the change at their level and 
invokes Propogate_Change method 304 in their parent, and 
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so on. At the top level (a GUI Server Component object like 
a plan, template, patient, etc.), the stack is included in the 
change even mat is distributed to all the CORBA clients that 
have registered for change notices. 

When the client receives the change notice, the client pops 
the change entries off the stack. Each change entry identifies 
the change at each level. If the user of the client application 
is not able to access the element that changed, the change 
notice may be ignored. 

For example, an order result value is updated (set by a 
client) during plan delivery. The Attribute of the result object 
creates a change stack object and places the first entry 
identifying itself as having changed. Attributes need to 
notify all of the rule expressions that depend on them using 
a notification mechanism provided in the CORBA standard 
referenced above. Next, it invokes the Propogate_Change 
method in its parent, an Order Instance object 364, as shown 
in FIG. 27. The Order Instance object 364 places an entry 
into the change stack identifying itself (e.g., its name, etc.) 
and invokes Propogate_Change in its parent, an Order 
object 358. The Order object 358 indicates that it changed 
and notifies its parent, a Composite Order 357. The Com- 
posite Order 357 pushes an entry into the stack and propa- 
gates the call up to its parent, a Result Node 359. The Result 
Node 359 pushes an entry into the stack and propagates the 
call up to its parent, a Node object 352. The Node object 
does the same and propagates the call to the Plan object 360 
that contains the Node. The Plan object 360 is the top level 
component. It provides the stack object with the call to the 
change event notification service. This service distributes 
the change notice to all GUI clients that have registered for 
change notices for this particular Plan object. 

Continuing the example, the client application receives 
the change notices and extracts the change stack object from 
the change event. The top entry in the change stack indicates 
that a change occurred in a specific patient's plan. If the 
client is no longer interested in changes to that plan, the 
notice may be ignored. If the client is currently displaying 
some aspect of the plan, it looks further into the change stack 
to see which node changed. If the client is interested in 
changes to the specific node, it looks within to find the result 
node 359, the composit order 357, the order 358 and so on. 
If it happens that the client is currently displaying the 
attribute that changed, it will find the new value at the very 
bottom of the stack. With this method, any change in a plan 
will be reflected on any user who is using the plan in real 
time. 

b. Factory Object Interface 

A factory object 305, as shown in FIG. 26, is an object that 
creates new instances of an object. Almost every server 
object class will have a corresponding Factory object class. 
Factories are arranged in the name tree to facilitate the 
creation of instances on different host machines, as illus- 
trated in FIG. 28. A Hosts directory 982 and Factories 
directory 984 is listed in the Name Tree Root 980 (among 
others). The Factories directory 984 contains a list of all the 
object factories in the system. The Hosts directory 982 
contains references to specific host directories that exist on 
the hosts they represent (e.g., the Host_l name context 
object runs on a computer host named "Host_l"). Each host 
directory contains a list of factories for all the objects that 
may be hosted on that machine (i.e., a user can control which 
hosts are to run which objects by including or excluding the 
object's factory in the host directory). 

An object that wishes to create a new object instance on 
a specific host will invoke the Create_New method 308 in 
the factory corresponding to the desired object and specify 
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the name of the host on which the new object will reside. If 
a host is specified, the factory traverses the name tree 
through the hosts directory 951 to find the factory residing 
on the desired host and forwards the Create_New request to 
that factory (without specifying a host name). When a s 
factory receives a create request without a host name, it 
creates the object instance on its own host. 

Other factories, in alternate embodiments, may look at the 
load and capacity of a collection of hosts and allocate the 
new object to the host with the most available storage and 1Q 
CPU capacity. 

c. Container Object Interface 

All of the GUI server objects that function as containers 
support the standard container interfaces (as seen in FIG. 26) 
in addition to the standard server object interfaces. The 
Container object 306 interfaces provide client objects with a 15 
standard way to add and remove items from containers, 
obtain an item within a container (the Resolve method 309), 
and list the names of the items within the container. In an 
embodiment, these interfaces will conform to the CORBA 
Standard Services 2.0 specification for containers. In an 20 
alternate embodiment, the container services may be able to 
use other environments, such as MAC windows. 

2. Library 

Every user may have their own library or link to a 
common library shared by others. The library function is 25 
implemented to handle a hierarchy of libraries that roughly 
correspond to the organization's structure (e.g., network, 
facilities, departments, etc.). 

FIG. 29 illustrates an example library hierarchy according 
to the present invention. Each physician may have their own 30 
library. Each library at the bottom of the tree is able to see 
items up through the hierarchy all the way to the top. Library 
items added at the top level are available to everyone within 
the network. Library items placed in the next level down are 
available to all users working in that type of facility (e.g., 35 
Nursing Home or Rehabilitation Center). Items added at the 
next level down are available to all users within the specific 
facility. Library items added at the lowest level are only 
available to the individual user. 

The content within a library at a given level in the 40 
hierarchy may also be organized in a hierarchy by depart- 
ment and category to organize the items stored in the library. 
This facilitates retrieval. 

a. System_Library Object Interfaces 

FIG. 30 illustrates the services provided by the library 45 
objects and the items contained within the library. System_ 
library objects 400 maintain the hierarchy of libraries across 
the network. Within a given library exists a collection of 
items stored in the library. Any client application (as in 
client-server design) interacts directly with the User__ 50 
Library objects 402. A User__Library instance is associated 
with every user 495 and connects to the System_Library 
hierarchy as a leaf node. User__Library objects 402 traverse 
up the library hierarchy through the ancestor chain and build 
a tree of library items from the union of all items in the 55 
System_Library object 400. They allow the client applica- 
tions to set preferences that identify which items are dis- 
played (presumably frequently ordered items) and which 
items are hidden (items a given user does not typically use). 

(i) Root Context Attribute 60 
The Root_Context attribute 405 holds the object refer- 
ence to the root container of the library at this level in the 
hierarchy. This container holds other containers and the top 
level library items in this library. 

(ii) Parent Library Attribute 65 
Parent Library attribute 406 maintains the link to the 

library above this one in the hierarchy.- 
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(hi) Children Libraries Attribute 
Children Library attribute 407 maintains references to the 
libraries below this on in the hierarchy. 

(iv) Register and Unregister Methods 

Register and Unregister methods 408 and 409 allow client 
applications to register and unregister for notifications of 
changes made to the library. When registered, a client 
application will receive notice when items change in the 
library at this level. 

(v) Find Item Method 

The Find_Item method 410 allows a client application to 
search through the library to find all the items that match the 
specified attributes and search criteria. The method returns a 
container holding the matching library items, or actually 
references to the items. 

(vi) Create Context and Create Libltem Methods 

The System_library object 400 serves as an object 
factory for library context (container 401) and library item 
objects. Create Context and Create Libltem methods 411 or 
412 create a new instance of the specified type of object. The 
new instance is not associated with a context and is essen- 
tially empty. The client application is expected to initialize 
the object and insert it into the appropriate context (by 
traversing to the desired context and invoking the Add__Item 
method 413 with the reference of the new object). 

b. User Library Object Interfaces 

The User_Library object 402 provides an interface to the 
client components. Its principle function is to provide an 
iterator to client components that allows them to iterate 
through the library items the user has indicated they wish to 
see. 

(i) User Attribute 

The User attribute 414 provides a link to the User object 
405 associated with a specific GUI user. In an embodiment, 
every User_Library object 402 instance is associated with 
one user. 

(ii) Get__Tree_Iterator Method 

The Get__Tree_Jterator method 415 returns an iterator 
object that is able to traverse through the tree of library 
items. The library tree iterator object is able to return 
references to library items the user has not hidden (using the 
Hide_Jtem method 416). The library tree iterator is able to 
keep abreast of library changes (in near real-time) and 
returns only current references to client components (e.g., a 
client invokes the Get_Tree__Iterator method 415 and 
begins traversing the tree, then another user adds a library 
item somewhere in the hierarchy; the iterator will return the 
reference to the new item if it traverses the area in the tree 
where the new item was just added). 

(hi) Hide__Item Method 

The Hide_Jtem method 416 allows a user to remove an 
item from the tree that the library iterator traverses through. 
Once hidden, the library iterator will not return the reference 
to the item. The item may be brought back using the 
Show_Item method 417. 

(iv) Show-Item Method 

The Show_Item method 417 searches through the library 
hierarchy for the specified item and, if it finds one, includes 
it in the tree of items the library iterator traverses through. 

c. LibContext Object Interfaces 

The LibContext object 403 inherits interfaces from the 
general Container object. It may contain other LibContext 
objects or Libltem objects. 

d. Libltem Object Interfaces 

The Libltem object 404 specifies interfaces that all library 
objects must support (e.g., inherit from). 

e. Library Item Objects 
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Each type of library object, as shown in FIGS. 27 and 30, 
possess interfaces specific to the object class. These inter- 
faces are discussed in detail below. 

3. Template, Plan and Patients 

This section describes the interfaces for the GUI server 
objects. FIG. 27 illustrates the relationships between the 
GUI server objects. 

a. Template Object Interfaces 

Template objects 348 are stored in either the system or 
user library. They contain Virtual Time Slot objects 349 that, 
in turn, contain Node objects 352 and Template objects 348. 
A template object 348 can also be embedded within another 
template (i.e., as a sub-plan). Template objects 348 have a 
name and attributes like all GUI server objects. They also 
support the Container and Archive interfaces. 

(i) Start__Node Attribute 

Start„Node attribute 370 allows clients to obtain the first 
node in the template, the start node. From this node, the 
client can traverse through all of the nodes in the plan. 

(ii) Get_Node_List_Attribute 

A client may get a list of object references to all the nodes 
in a template by invoking the Get_Node_List attribute 371. 
This attribute returns a list of object references. 

(iii) Get_Time_Slot_List Attribute 

A client may get a list of the virtual time slot objects in the 
template by invoking the Get_Time_Slot__Ust Attribute 
372. This attribute returns a list of object references. 

(iv) Lock and Unlock Methods 

Clients that wish to make changes to a template will need 
to obtain a lock on a template instance. The Lock method 
373 allows clients to obtain a lock or indicates the template 
is currently locked by another client. Clients must obtain a 
lock before making changes to a template. Once the changes 
are complete, they must call the Unlock method 374 to free 
the template instance so that other clients may make 
changes. Clients that only need to view a template (without 
making changes) need not obtain a lock on the template, but 
they should register to receive change notifications so they 
can show users updates to the template when changes are 
made by others. 

(v) Register and Unregister Methods 

Clients that wish to be notified when changes occur in 
templates must register with the template object instance by 
using register method 375. When they no longer wish to 
receive change notifications, they should unregister by using 
unregister 376. 

b. Plan Object Interfaces 

Plan objects 360 represent the patient's integrated plan. 
There is one instance of a Plan object for every patient. 
These objects contain all the orders from assigned templates. 
A Plan contains a network of Node objects 352 for Orders 
that have not yet been scheduled. Scheduled orders are 
moved into the Real Time Slot object 363 corresponding to 
the scheduled start time of the Order. 

c. Patient Object Interfaces 

Patient objects 361 represent patients in the GUI system. 
There is one instance of a Patient object for each patient. The 
Patient object maintains connections to the patient's plan 
object 360, history object 362 and other items (e.g., 
medications, conditions and alerts). 

d. History Object Interfaces 

History objects 362 maintain the order history for the 
patients in the GUI system. There is one instance of a 
History object for each patient. The History object 362 
maintains connections to the object archives 307 (see FIG. 
26) for all of the orders that have been completed for the 
patient. It also maintains indices to facilitate fast searches 
based on templates and orders, and time period. 
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e. Virtual Time Slot Object Interfaces 

Template objects 348 contain a list of Virtual Time Slot 
instances for each time slot in the template. Virtual Time Slot 
objects 349 maintain the state of individual time slots in a 
5 template. 

f. Real Time Slot Object Interfaces 

The Real Time Slot Objects 363 represent actual time 
intervals. They are contained within Plan objects to hold 
orders scheduled to start within a specific time interval. Real 
10 time slot objects 363 indicate their start time and duration. 
When orders are scheduled, they are moved from nodes into 
Real Time Slot Objects. The Scheduling and tasks manage- 
ment client software uses the time slots to display tasks 
scheduled for individual users. 

g. Result Node Object Interfaces 

15 The Result Node objects 359 represent the list of result 
nodes that can proceed from a Node object 352. Result Node 
objects 359 maintain information on the result node and the 
decision nodes to allow the clients to reconstruct a full node 
triplet by combining the information from the Node object 

20 352 and the Result Node objects 359. 

h. Composite Order Object Interfaces 

Composite orders 357 are containers for multiple orders 
that are grouped together. 

i. Order Object Interfaces 

25 The Order object 358 fully describes generalized orders in 
the GUI system. The Order Instance object 364 maintains 
the data that qualify the order, the order's life cycle, and the 
results gathered when the order is filled. Each order contains 
at least one order instance object. 

30 j. Order Instance Object Interfaces 

Order Instance objects 364 capture the state of an instance 
of an order. Ongoing orders will have multiple order 
instances. Each order instance has attributes that qualify the 
order, hold result values, and mark start and end times. Order 

35 Instance objects 364 also have a life cycle object within that 
maintains the current state of the order and acts on events 
that transition the order to its various states, 
k. If Rule Object Interfaces 

If Rule Objects 353 contains three elements: a Probability 
40 Attribute 377, Destination attribute 378, and an Expression 
Object 354. The Probability attribute maintains the prob- 
ability that the branch associated with this rule is taken (on 
average). The Destination attribute indicates the nodes that 
will be activated when the rule fires. 
45 I. Expression Object Interfaces 

Expression Objects 354 maintain logical expressions. 
They not only contain the string representation of the 
expression, but the references to all the attributes they 
depend upon. They monitor the life cycle of the orders they 
50 depend upon and when the life cycle changes state, they 
check to see if they can now evaluate the expression, 
m. Life Cycle Object Interfaces 

Life cycle objects 356 maintain state tables for attributes, 
orders, templates, plans, etc. The state tables have a state and 
55 accept events that advance the life cycle to a new state. It 
may support the activation of methods when state transitions 
occur. 

n. Attribute Object Interfaces 

Attribute objects 355 hold all the data in plans, templates, 
60 orders, patients, etc. available to GUI for decision making 
purposes. 

Form Object Interface 

Form object 430 (see FIG. 30) provides all attributes 
associated with an order object 358 for collecting results 
65 data. It provides all information needed to display results 
data in the GUI, The form object can represent any form 
including HTML forms. 
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IX. CONCLUSION 11. The apparatus of claim 9, wherein the stored program 

The foregoing description of the preferred embodiments adds a second order icon image in response to the activation 

of the present invention has been provided for the purposes of an add button corresponding to the second order icon 

of illustration and description. It is not intended to be image. 

exhaustive or to limit the invention to the precise forms 5 L2. A method for displaying a graphic representation of a 

disclosed. Obviously, many modifications and variations mcd ical treatment plan, comprising the steps of: 

will be apparent to practitioners skilled in the art. The ... c . 

embodiments were chosen and described in order to best 1 v KOU ""^ rc P rcscntm e a fiist 

explain the principles of the invention and its practical me ea ' 

applications, thereby enabling others skilled in the art to providing a second set of icon images representing a 

understand the invention for various embodiments and with second medical treatment; and 

the various modifications as are suited to the particular use combining the first set of icon images with the second set 

contemplated. It is intended that the scope of the invention 0 f icon images to obtain a third set of icon images 

be defined by the following claims and their equivalents. representing a medical treatment including the first and 

We claim: second medical treatment. 

1. A data processing apparatus, comprising: 13. The method of claim 12, wherein the method further 
a display for displaying data; includes the step of arranging the first set of icon images in 
input means for supplying input data; corresponding time slots with the second set of icon images, 
a storage location, coupled with the display and the input 14. The method of claim 12, wherein the step of providing 

means, for storing data, images, and programs; and 20 a first set of icon images includes the step of providing the 

processing means, coupled to the display means, the input first set of icon images in a flow chart and the step of 

means, and the storage means, for controlling the providing a second set of icon images includes the step of 

storage means, the input means, and the display means providing the second set of icon images in a flow chart. 

in response to stored programs and input data to 15 T*® method of claim 12, wherein the method further 

perform data processing operations; ^ includes the step of assigning the first set of icon images to 

wherein the display includes, 4 p *J lc i?' . , 

a plurality of graphic icon images, stored in the storage 16 ' ™* mctbod of claim ^ whcrein the method stc P of 

location, arranged on the display representing a providing a first set of icon images includes the step of 

medical treatment plan; providing an order triplet, 

wherein the stored programs includes, 30 . * 7 ' The me i hod °j claim 1 16 > , wher ^ the orxler 1 tri Pj et 

aprogramformergingafirstsetofgraphiciconimages mc * de * ^ ^J"?'. res ^l node and flow control node^ 

representing a first treatment plan with a second set 18 ^ e m f° d 0 ci ? m U > wherem ^ me *° d Step 0 

of graphic icon images representing a second treat- P rov ^ n S a se j of 1C0n ima Sf 1Qdudes ^ sle P of 

ment plan to obtain a combined treatment plan. P r ° vld ^ * first order icon image having a corresponding 

2. The apparatus of claim 1, wherein the first set of 35 order p descn P 1 ^ a * d * e ™*° d step of providing a second 
graphic icon images are assigned to a patient. set of icon images includes the step of providing a second 

3. Tne apparatus of claim 1, wherein the first set of 0rde o r !£ D ima f J 13 * 1 ^ a ^sponding order description. 

_ •„•.„„ j , . r _ . • ■ 19. The method of claim 18, wherein the combining step 

graphic icon images and tne second set ol graphic icon r • . ^ . 

images are arranged in a first flow chart view and a second * lrther , ? cludes * e sl f <*<*«°P?°e fct order descri P" 

chart view, respectively. <° S 'T^ { ^T' ■ ,u „• • . 

4. The apparatus of claim 1, wherein the first set of . 20 ' ™ e , / 7 combining step 
graphic icon images includes at least one order triplet, the former includes the step of detecting conflicting order 
order triplet having an order node, result node and flow descnptions in the first order description and the second 
control node 0 description. 

- -n. ' ri-iu-iu-. , 21. The method of claim 19, wherein the combining step 

5. The apparatus of claim 1, wherem the input means 45., .,, , ' . 

includes a mouse further includes the step of removing a duplicate order 

6. The apparatus of claim 1, wherein the process means description in the first order description and the second order 
includes a processor. e i? J ™° n ' , , , . , . , 

7. The apparatus of claim 1, wherein the first set of . 22 ' ^ method <* daim 2i > whe ™ ^ du P llcatc order 
graphic icon images includes at least a first icon image 50 15 £ m ° ve d m ™*>? nse * * user supplied rule. 

having a first medical order description responsive to input M art ' clc of mM ^V?K c0 *P u ' cr 1 rcadablc 

data and the second set of graphic icon images includes at P ro f am code means erabodied therem * r displaymg t 

least a second icon image having a second medical order medical moment f lan ; mc co f m P uter readablc P ro S ram ™ 6t 

description responsive to input data, and the combined means m the of manufacture composing: 

treatment plan includes a third icon image representing the 55 computer readable program code means for causing a 

first and second medical order description. computer to generate an image on a display represent- 

8. The apparatus of claim 7, wherein the stored program m S a first medical treatment; 

eliminates duplicate order descriptions in the first medical computer readable program code means for causing a 

order and the second medical order. computer to generate an image on a display represent- 

9. The apparatus of claim 1, wherein the first set of 60 ing a second medical treatment; and 

graphic icon images are arranged in a chronological computer readable program code means for causing a 

sequence and a first icon image in the first set of graphic icon computer to combine the image representing the first 

images represents a medical order. medical treatment with the image representing the 

10. The apparatus of claim 9, wherein the stored program second medical treatment to display a combined medi- 
deletes the first order icon image in response to the activa- 65 cal treatment image. 

tion of a delete button corresponding to the first order icon 24. The article of manufacture of claim 23, wherein the 

image. article of manufacture further includes a computer readable 
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program code means for causing a computer to generate a 
chart view of the image representing the first medical 
treatment and the image representing the second medical 
treatment. 

25. The article of manufacture of claim 23, wherein the 
article of manufacture further includes: computer readable 
program code means for causing a computer to generate the 
image of the first medical treatment in time slots on a display 
corresponding to the image of the second medical treatment. 

26. The article of manufacture of claim 23, wherein the 
article of manufacture further includes a computer readable 
means for causing a computer' to assign the image repre- 
senting the first medical treatment to a patient. 

27. The article of manufacture of claim 23, wherein the 
image representing the first medical treatment includes an 
order icon image having a corresponding order description. 

28. The article of manufacture of claim 27, wherein the 
order icon image is an order triplet including an order node, 
a result node and a flow control node. 
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29. The article of manufacture of claim 28, wherein the 
article of manufacture further includes computer readable 
means for causing a computer to assign a result value to the 
result node image. 

30. The article of manufacture of claim 27, wherein the 
image representing the second medical treatment includes an 
order icon image having a corresponding order description. 

31. The article of manufacture of claim 30, wherein the 
article of manufacture further includes computer readable 
means for causing a computer to compare the first order icon 
image description to the second order icon image descrip- 
tion. 

32. The article of manufacture of claim 30, wherein the 
article of manufacture further includes computer readable 
means for removing duplicate order descriptions in the 
combined medical treatment. 



02/20/2004, EAST Version: 1.4.1 



